BiglyBT crashes and disappear while downloading

[Ghost-chu]

• Windows 11 24H2 (26100)

Java 23 (64 bit)
  Eclipse Adoptium
c:\program files\eclipse adoptium\jdk-23.0.0.37-hotspot

SWT v4964r8, win32, zoom=100, dpi=144
Windows 11 v10.0, amd64 (64 bit)
B3.7.0.0/4 az3 zh_CN

logs.zip

I simply added a magnet and started the download and BiglyBT crashed very quickly. I packed up any log files that might be of value and uploaded them in the hopes that it would help resolve the issue.

[parg]

DIdn't we already work out that Java 21... was borked for you?

[Ghost-chu]

DIdn't we already work out that Java 21... was borked for you?

However it's Java 23?

[parg]

Did you report the issue with 21?

[Ghost-chu]

Did you report the issue with 21?

No and sorry, I think this is a duplicate question. I just found the hs_err file and it seems that the GC Thread crashed again ......

Uhhh, I'll report the issue to OpenJDK or Adoptium.

[parg]

thanks :)

[Ghost-chu]

thanks :)

Unfortunately Oracle seems to require a small test container program, but since it's not clear how this is triggered, I think that's the end of what I can do.

Hi,

Regarding the random crashes observed with “C:\Program Files\BiglyBT\BiglyBT.exe” .We need a small self-contained test program (ideally in a single class or at least a very small number of classes) with a simple set of steps to reproduce it, and not just a pointer to a GitHub repo with a complete application

Thanks
Raja

[parg]

Just send them the JVM dump files and say you can't reproduce it with a small program. I've done it before.

[Ghost-chu]

@parg I think I can't continue this bug report, I received the mail from OpenJDK team:

Hello

We are unable to use the reproducer as provided. Code must be submitted with the bug report directly. Content stored in external locations (such as, but not limited to, iCloud Drive, Dropbox, Google Drive, Microsoft OneDrive, or GitHub) can not be accepted.

Please send a reproducer (raw source code of the test) on the understanding that the code:

    - is owned by you, or you are in possession of all associated rights;

    - will enter the public domain;

    - can be used, without any conditions or obligations, by any user for any purpose.

Thanks
Raja

I don't think I have the right to license these codes into public domain or use by any user for any purpose, as they don't belong to me and are restricted by the agreement and it looks like only you can do this (as the code owner).

Here is my original mail:

Hi,

I have not been able to reproduce this bug in smaller Java programs, but BiglyBT does have this problem and the developers of BiglyBT are advising me to get in touch with OpenJDK as it appears in various OpenJDK distributions and also Ubuntu OS and covers Java 21 and all higher versions.

Java 8 and Java 17 seems not affected. I just reproduced the error again and created a minidump, appreciate your time and work:)

https://drive.google.com/file/d/1XkOTrP7THfvBozgWRKi0jk3_920v3PKf/view?usp=sharing

Thanks!

Ghost

[parg]

The world is just crammed full of lazy fuckers who don't give a shit about actually doing their jobs, isn't it?

[Ghost-chu]

The world is just crammed full of lazy fuckers who don't give a shit about actually doing their jobs, isn't it?

I'm concerned about whether this will affect BiglyBT's ability to upgrade to a higher OpenJDK version in the future. OpenJDK refuses to use full application tests, however there is simply no way for me to reproduce this issue in smaller applications. In fact the code in question is in the garbage collector code at the Native level, which I know nothing about and can't do anything about.

I have tested several JDK distributions, Adoptium, Zulu and they all have the same problem. I believe this is an issue in OpenJDK. Unfortunately I can't take this issue any further because I can't change the license agreement on behalf of the contributors of this code, which is against the License, and is unethical and against the law, but OpenJDK apparently requires me to do so.

Who knows if this will become a hidden issue and lead to bigger problems or financial losses at some point in the future? But for now, that's as far as I can go.

Anyway, thank you for your (many years of) hard work and continued maintenance of this project. I will be fixed on Java 17 for now.

[Ghost-chu]

I found this piece of information while looking into hs_err:

Stack slot to memory mapping:

stack at sp + 0 slots: 0x00000211a89a3c00 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00
stack at sp + 1 slots: 0x000004002ac36780 is a zaddress: java.lang.Class 
{0x000004002ac36780} - klass: 'java/lang/Class'
 - ---- fields (total size 22 words):
 - private volatile transient 'classRedefinedCount' 'I' @12  0 (0x00000000)
 - injected 'klass' 'J' @16  2156655424 (0x00000000808bf340)
 - injected 'array_klass' 'J' @24  0 (0x0000000000000000)
 - injected 'oop_size' 'I' @32  22 (0x00000016)
 - injected 'static_oop_field_count' 'I' @36  0 (0x00000000)
 - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40  null (0x0000000000000000)
 - private transient 'name' 'Ljava/lang/String;' @48  "dev.onvoid.webrtc.RTCRtpTransceiver"{0x000004002ac36830} (0x01000ab0da0c2630)
 - private transient 'module' 'Ljava/lang/Module;' @56  a 'java/lang/Module'{0x000004000b051190} (0x010002c144642630)
 - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64  a 'java/net/URLClassLoader'{0x000004000b050f48} (0x010002c143d22630)
 - private transient 'classData' 'Ljava/lang/Object;' @72  null (0x0000000000002930)
 - private transient 'packageName' 'Ljava/lang/String;' @80  "dev.onvoid.webrtc"{0x0000040025f93d10} (0x0100097e4f442630)
 - private final 'componentType' 'Ljava/lang/Class;' @88  null (0x0000000000000000)
 - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96  null (0x0000000000000000)
 - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104  null (0x0000000000000000)
 - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112  null (0x0000000000000000)
 - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120  null (0x0000000000000000)
 - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128  null (0x0000000000000000)
 - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136  null (0x0000000000000000)
 - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144  null (0x0000000000000000)
 - injected 'protection_domain' 'Ljava/lang/Object;' @152  a 'java/security/ProtectionDomain'{0x0000040025f94840} (0x0100097e52102630)
 - injected 'signers_name' 'Ljava/lang/Object;' @160  null (0x0000000000000000)
 - injected 'source_file' 'Ljava/lang/Object;' @168  null (0x0000000000000000)
 - signature: Ldev/onvoid/webrtc/RTCRtpTransceiver;
 - ---- static fields (0):
stack at sp + 2 slots: 0x000000000000000d is an unknown value
stack at sp + 3 slots: 0x008005586cf00000 is an unknown value
stack at sp + 4 slots: 0x00000211aaee9260 points into unknown readable memory: 0x00800160a1e90000 | 00 00 e9 a1 60 01 80 00
stack at sp + 5 slots: 0x00007ffb34f7e2a4 jvm.dll
stack at sp + 6 slots: 0x0000006423affb60 points into unknown readable memory: 0x0000006423efee90 | 90 ee ef 23 64 00 00 00
stack at sp + 7 slots: 0x0000000000000d0a is an unknown value

So I disabled the WebTorrent plugin to avoid triggering any WebRTC code. Now BiglyBT seems to become stable ...... This is very interesting and I will continue to investigate.

[Ghost-chu]

I've determined that the library dev.onvoid.webrtc used by WebTorrent uses Native code in the location where the problem occurs. This could be the cause of the problem.

I'll restart running the test for a long time to test stability with the WebTorrent plugin disabled.

[parg]

hmm, interesting, thanks for keeping on this

[Ghost-chu]

I have been testing stability performance under high load for an hour straight and so far so good. Before disabling WebTorrent, BiglyBT would probably take less than 1 minute to crash, but now I see no signs of crashing at all.

To test for crashing issues, simply enable the WebTorrent plugin and somehow make BiglyBT connect to a WebTorrent peer.

[parg]

But the crash is always in the GC thread?

[Ghost-chu]

But the crash is always in the GC thread?

Yes it always on GC thread. I also tried ZGC and seems it also on GC worker thread.

[parg]

Maybe https://github.com/devopvoid/webrtc-java/commit/ccd7d5a253cda728de37d52db41092c8ae8d1cdc ?

[parg]

I released plugin version 1.5.4 containing a snapshot build of the WebRTC JNI component to BETA users for testing

[Ghost-chu]

I released plugin version 1.5.4 containing a snapshot build of the WebRTC JNI component to BETA users for testing

I ran a quick test on 1.5.4 and it looks like the problem is resolved.
I am still running longer tests to confirm that this issue is indeed fixed.