JDK-7078412 : SIGSEGV in compareAndSwapLong
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs22,7
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: generic,x86
  • Submitted: 2011-08-12
  • Updated: 2012-11-29
  • Resolved: 2012-01-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u4Resolved
Related Reports
Duplicate :  
JDK-7163861 - Netbeans 7.1.1 crashed while selecting a source file Tab
Duplicate :  
JDK-7083269 - "assert(iterations < (uint)max_jint) failed" during 6916968 verification
Relates :  
JDK-8004124 - Handle and/or warn about SI_KERNEL
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb57e1ffc, pid=17932, tid=2682231696
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) Client VM (22.0-b01-internal-201108060545.et151817.hs22b01_in_7u-fastdebug mixed mode linux-x86 )
# Problematic frame:
# J  sun.misc.Unsafe.compareAndSwapLong(Ljava/lang/Object;JJJ)Z
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Comments
EVALUATION I checked the linux source code and as I understand SI_KERNEL should indeed not be seen by a user process and is used when the kernel finds the process in a unexpected state that it cannot recover from. hs_err log files show no evidence of problems on the VM side. It looks like the kernel is misbehaving under stress.
24-01-2012
EVALUATION The three attached hs_err logs are all mysterious. Here's the instructions around the crash points. siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x00000000;; ;; b57e1fec 83 c4 08 add $0x8,%esp ;; b57e1fef 8b 45 fc mov 0xfffffffc(%ebp),%eax ;; b57e1ff2 c7 87 2c 01 00 00 00 00 00 00 movl $0x0,0x12c(%edi) ;; --------------- ;; b57e1ffc c7 87 30 01 00 00 00 00 00 00 movl $0x0,0x130(%edi) ;; b57e2006 8b 4f 20 mov 0x20(%edi),%ecx ;; b57e2009 c7 81 84 00 00 00 00 00 00 00 movl $0x0,0x84(%ecx) ;; b57e2013 81 7f 04 00 00 00 00 cmpl $0x0,0x4(%edi) ;; b57e201a 0f 85 ff ff ff ff jne 0xb57e201f ;; siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x00000000;; ;; b57bafec 83 c4 08 add $0x8,%esp ;; b57bafef 8b 45 fc mov 0xfffffffc(%ebp),%eax ;; b57baff2 c7 87 2c 01 00 00 00 00 00 00 movl $0x0,0x12c(%edi) ;; --------------- ;; b57baffc c7 87 30 01 00 00 00 00 00 00 movl $0x0,0x130(%edi) ;; b57bb006 8b 4f 20 mov 0x20(%edi),%ecx ;; b57bb009 c7 81 84 00 00 00 00 00 00 00 movl $0x0,0x84(%ecx) ;; b57bb013 81 7f 04 00 00 00 00 cmpl $0x0,0x4(%edi) ;; b57bb01a 0f 85 ff ff ff ff jne 0xb57bb01f ;; siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x00000000;; ;; b58c1fed f0 c7 00 01 00 00 00 lock movl $0x1,(%eax) ;; b58c1ff4 89 50 04 mov %edx,0x4(%eax) ;; b58c1ff7 89 58 08 mov %ebx,0x8(%eax) ;; b58c1ffa 83 ee 0c sub $0xc,%esi ;; --------------- ;; b58c1ffd 0f 84 3d 00 00 00 je 0xb58c2040 ;; b58c2003 f7 c6 03 00 00 00 test $0x3,%esi ;; b58c2009 0f 84 11 00 00 00 je 0xb58c2020 ;; b58c200f 68 88 50 6c 01 push $0x16c5088 ;; b58c2014 e8 00 00 00 00 call 0xb58c2019 ;; b58c2019 60 pusha ;; b58c201a e8 d1 1b ff ff call 0xb58b3bf0 ;; In the first two edi is the current thread pointer and it doesn't seem possible for the first to succeed but the second one to fail. It's nulling out vm_result and vm_result_2. The third is fairly impossible, since a jcc can't SEGV. I'm not sure what's going on but I don't think it's a real bug on our side.
04-10-2011
EVALUATION This seems to be some weird linux behaviour. notice that the si_code=128, which is SI_KERNEL and that si_addr is always 0000 which doesn't agree with the actual instructions that we faulted on. siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x00000000;; Registers: EAX=0x00000001, EBX=0x0000944c, ECX=0x00000400, EDX=0x01883a88 ESP=0x9fdf8d70, EBP=0x9fdf8da8, ESI=0x0000944c, EDI=0x0a14a000 EIP=0xb57e1ffc, EFLAGS=0x00010246, CR2=0x00000000 ;; b57e1ffc c7 87 30 01 00 00 00 00 00 00 movl $0x0,0x130(%edi) Searching google for si_code=128 finds many hits and so does searching bugtraq. The crashes occur pretty much anywhere in the system, including C++ code so I don't think this is connected to compiled code at all. So for some reason the kernel decides to send us a SIGSEGV out of the blue and it's not obvious why.
07-09-2011