BiglyBT wedges nearly daily

[runderwo]

Hi, I just migrated from Azureus to BiglyBT 3.4.0 in Debian and while things are mostly working fine, the program completely hangs about once a day. Even kill -TERM is not responding and SIGKILL must be issued to get rid of the process. While Azureus was full of bugs, this was not one of them :-)

The JVM is 17.0.10+7-1~deb12u1 from Debian.

What should I do to best gather information that would be needed to find the root cause?

• OS and version
• BiglyBT Version Number
• For *nix: Desktop Environment

[parg]

Check out https://github.com/BiglySoftware/BiglyBT/wiki/Diagnostics

[runderwo]

Edit: nevermind, I forgot I need to manipulate a network namespace in my case. I'll check on it next time.

[runderwo]

I found that curl connects but completely hangs with that query. It's as if the JVM is completely wedged. Only a kill -9 gets rid of the process.

[parg]

Check the Debug_1/2.log files (and maybe SlowUI_1/2.log) in case anything is being logged prior to things hanging up

[runderwo]

Ok, I think I got some useful logs from a hung instance. debug.zip

[parg]

Are you actually using I2P? There's a bunch of errors regarding failures contacting a router on "10.0.0.1:7654". If not then disable the I2P Helper plugin.

You have a large number of UDP listener threads running on port 0 which makes no sense...

Perhaps you could send over a full debug.zip (generate it from the Help menu) - email it to paul@biglybt.com if you want

[runderwo]

I have not configured anything to listen on UDP port 0 - perhaps it's some artifact of migrating an old config from Vuze? The i2p configuration is correct. Are there other specific logs I could provide? debug.zip is far too detailed.

[parg]

VPNHelper plugin installed?

You can generate "config changes" - go to Help->Advanced->Show Configuration Changes

You might want to sanitize it before posting it.

[runderwo]

I don't even see a VPNHelper plugin in the available list, and definitely not installed.

Here is the output you asked for with parts marked as snipped: configchanges.txt

[parg]

Nothign sticks out there :( Do you really use SOCKS? It generally sucks.

[runderwo]

Yes, to force all traffic with non-i2p destination through tor. I agree, it's not the greatest performance-wise but it's good enough in practice and shouldn't cause the whole process to get stuck. Is there any problem you see with using the Java 17 JRE from Debian?

[runderwo]

Seems like it gets very slow before wedging which makes me think it might be a GC death spiral. Do you have a set of JVM flags and/or process for tracking down leaks?

[parg]

View->Log Views->JVM Info

https://github.com/BiglySoftware/BiglyBT/wiki/Performance-Tweaks#memory-usage

[runderwo]

There appears to be a memory leak. No matter how high I set -Xmx, eventually "alloc" bumps up against it, "free" dwindles to a few megabytes and the program becomes unresponsive. I have noticed in the log that "alloc" generally merely creeps up slowly over a period of hours; at times, it jumps more than a gigabyte in a matter of seconds, but I guess that could be the JVM allocating additional heap in big chunks. Is there a process for obtaining and analyzing a heap dump or do I need to figure it out myself?

[parg]

You could try https://visualvm.github.io/

[runderwo]

Heap objects in screenshot

[parg]

How many active downloads (i.e. Downloading or Seeding) do you have? 11,000 ?

[runderwo]

I noticed that max active torrents was set to 0, so I set it to 100. Maybe this was an artifact of migrating. Let's see if that behaves better.

[runderwo]

Looks like that configuration error was the problem since memory usage is much more consistent now. Thanks for your help! Perhaps the setting did not get migrated correctly, in case that's worth looking into.

[parg]

Glad it worked out!