Opened 9 years ago
Closed 9 years ago
#554 closed defect (not a bug)
SIGSEGV (0xb) at pc=0xb6d4d69b
Reported by: | DISABLED | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 0.8.12 |
Component: | unspecified | Version: | 0.8.11 |
Keywords: | Cc: | ||
Parent Tickets: | Sensitive: | no |
Description
Hi,
this crash seems to be similar to #526 http://trac.i2p2.i2p/ticket/526
and presented itself to me on an up-to-date Arch Linux (3.1.1-1-ARCH #1
SMP PREEMPT) installation as of 2011-11-20 on one occasion. I have not
encountered any other crashes.
I2P version: 0.8.11-0
Java version: Sun Microsystems Inc. 1.6.0_22 (OpenJDK Runtime Environment 1.6.0_22-b22)
Wrapper version: 3.5.12
Platform: Linux i386 3.1.1-1-ARCH
Processor: uninitialized (core2)
Jbigi: Locally optimized native BigInteger? library loaded from file
Encoding: ANSI_X3.4-1968
JRE package installed:
local/openjdk6 6.b22_1.10.4-1
https://www.archlinux.org/packages/extra/i686/openjdk6/
I2P package built and installed:
local/i2p 0.8.11-1
https://aur.archlinux.org/packages.php?ID=2033
As it was requested from the other user in the #526 ticket discussion,
I'm adding some more information:
7562d0ff8e437cd2061a4c32253db13d /opt/i2p/libjbigi.so
9bbfbbe59f8251461a709007050a50f0 /opt/i2p/libjcpuid.so
GMP package installed:
local/gmp 5.0.2-3
https://www.archlinux.org/packages/core/i686/gmp/
Relevant logs are in the attachment.
Cheers
Subtickets
Attachments (1)
Change History (2)
Changed 9 years ago by
comment:1 Changed 9 years ago by
Resolution: | → not a bug |
---|---|
Status: | new → closed |
Thanks for the report.
In #526, the crash was in native modPow(), which we explicitly call, and is known to be a problem if the library is for the wrong processor, for example. And iirc it was repeatable.
Here, it's in DatagramSocket?, just reading an inbound UDP packet, nothing we are explicitly doing in native code. This is very unlikely to be anything we caused or can do anything about. It could be due to flaky RAM or JRE bugs, for example. You may wish to run a RAM test, especially if it recurs. Your JRE looks relatively recent but you may wish to check for updates.
If it does recur, check to see if it happens in the same place (UDP receive).
Closing the ticket for now. If does happen repeatedly in the same place and a RAM test is good, please reopen the ticket.