search

airdcpp-web / airdcpp-webclient

Communal peer-to-peer file sharing application for file servers/NAS devices
https://airdcpp-web.github.io
175 stars 32 forks source link

Random crashes #403

Closed vestingz closed 3 years ago

vestingz commented 3 years ago

I am running AirDC++w 2.11.0 under Arch Linux (Linux 5.10.46-1-lts x86_64) in a screen session.

Lately, airdcppd crashes after a few hours of uptime. I am not sure about the reasons and the coredumps attached (#1, #2) don't seem to help much more either.

Is there a good way to debug this further? Thank you!

maksis commented 3 years ago

Are you able to get anything more useful if you get the stacktrace with gdb according to https://github.com/airdcpp-web/airdcpp-webclient/blob/master/.github/CONTRIBUTING.md#application-freezesdeadlocks ?

Looks like it's related to responding to a search so you could also run the application with the --cdm-hub parameter. It will then spam all incoming searches (and other hub commands) in the console. Try to catch the BSCH command that was received right before the application crashed.

vestingz commented 3 years ago

Thank you for your answer! :)

I have yet to see another crash but was able to retrieve more info through systemd-coredump: coredumpctl gdb PID-> thread apply all bt full. The output is here. I hope that this is somewhat helpful? If not, I will wait for another crash and then try the method you were suggesting.

I will also look into running airdcppd with the parameter you mentioned.

maksis commented 3 years ago

Unfortunately those logs don't show the exact code line where the crash happened, so I need something different

vestingz commented 3 years ago

Alright, I will post with an update here as soon as it happened again 👍

vestingz commented 3 years ago

So I had another crash, but I was unfortunately not able to follow the steps you suggested here, as the application does not freeze, but just exits.

I realized though that I had never attached the last console messages from before the crash, so here they are: https://0x0.st/-VCq.txt

Edit: Now I am just running with --cdm-hub and waiting for a crash.

maksis commented 3 years ago

Using --cdm-hub would be a really good start as then you would know the crashing search query that could possibly be used to reproduce the crash without waiting....

maksis commented 3 years ago

@vestingz did it stop crashing...? Version 2.11.1 will be released within the next few days, quite likely without a fix for this issue.

maksis commented 3 years ago

Version 2.11.1 is out so you should switch to that one. Remember to refresh your share as mentioned in the release notes (if auto refresh is disabled).

vestingz commented 3 years ago

@vestingz did it stop crashing...? Version 2.11.1 will be released within the next few days, quite likely without a fix for this issue.

Yes, it is running just fine since I used --cdm-hub 😄

Thank you very much for the update! I will switch asap and let you know in this thread if the problem persists. Have a good week :)

vestingz commented 3 years ago

Ok, I just had another crash with the last BSCH command before the crash being: BSCH J43N TO1/659309858 GE0 ANmovies TY2 The terminating message was the following: http://0x0.st/-WRX.txt

I would update the client now and run it again with --cdm-hub.

maksis commented 3 years ago

You should try performing the same search with another client (you can ask someone else to do it if you don't have one, you can also join the dev hub). The search query is simply "movies" with type directory and minimum size of 0.

vestingz commented 3 years ago

Had another crash with the last command before the crash being: FSCH TXQI +TCP4-NAT0 TO3/2897235652 GE0 ANFLAC TY2

Tried to understand that request from this reference but couldnt' really decipher it, save for "directory size greater 0 containing FLAC".

Tried to issue a similar search (directory size greater 1MiB containing FLAC) through my own frontend while watching the debug messages scrolling past and it seems the GE flag is not being used. Search results also contain plenty of directories smaller than 1MiB.

maksis commented 3 years ago

Have you tried to reproduce the crash as suggested in the previous comment?

maksis commented 3 years ago

@vestingz did the issue disappear?

vestingz commented 3 years ago

@vestingz did the issue disappear?

Judging from the service journal, not really - it still crashes every other day or so, but I mitigated by managing the daemon through a systemd service with Restart = on-failure. This just restarts the daemon after the crash. Sorry that I can't be of more help at this point :( Although the issue is not solved, I think this thread can be closed.