![]() ![]() 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. (Or, more likely, it will handle other reads from different threads/processes, until the hash checker reads the next piece.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. Once that happens, faster disk transfer rates won't make it go (appreciably) faster, a faster disk will just end up waiting longer for the process to request more bytes. And at some point (depending on the processor speed, memory pressure, etc.) the checker's speed becomes CPU bound rather than disk bound - more time is spent on calculations and memory management than on disk reads. Since only one of those 6 steps (number 2) involves any disk activity at all, hash checking is never going to saturate the disk's read bandwidth completely. Releasing the memory that holds the disk bytes.Looking up the expected hash value from the torrent data.Calculating a hash value for those bytes.Reading bytes from the disk into that memory.Allocating memory for the data to be read.But beyond that, the checking process isn't simply a matter of reading data from the disk. ![]()
0 Comments
Leave a Reply. |