Biglybt causing disk usage6/17/2023 Method entry point (kind = native) 2432 bytes Siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd6aaafe9d0 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) V JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x81 V JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x179 V JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2fb J .jman.AEThreadMonitor$1.runSupport()V+6 Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)Ĭ pthread_getcpuclockid+0x9 S U M M A R Y -Ĭommand Line: -Xmx256m =/opt/BiglyBT =/opt/BiglyBT -Dazureus.script=./biglybt 4Stack=true =9 -Xms1G -Xmx2G .Main # If you would like to submit a bug report, please visit: Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /opt/BiglyBT/core.43266) # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.0.1+7, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # A fatal error has been detected by the Java Runtime Environment: The BiglyBT calling this hasn't change in a long time either so I assume it is associated with a recent JRE update. Ubuntu 20.04 with all the latest updates.Ī couple of users have started frequently getting this crash in the last couple of weeks, not seen before (in 10+ years of running the Application, BiglyBT.
0 Comments
Leave a Reply. |