JVM exception reporter routine crashes

[dmik]

Sometimes, more often on SMP, when a fatal exception happens in JVM (e.g. memory access violation) and the respective exception handler tries to print out the exception information to the console and to the log file (starts with infamous words "A fatal error has been detected by the Java Runtime Environment"), the print routine fails on its own leaving an entry in POPUPLOG.OS2.

Here are some details about the place of the crash:

# .r
eax=00000a0d ebx=0326fb04 ecx=0326fb40 edx=0326fb28 esi=00000000 edi=21122640 
eip=1d395615 esp=0326faa4 ebp=0326facc iopl=0 rf -- -- nv up ei pl zr na pe nc 
cs=005b ss=0053 ds=0053 es=0053 fs=18b7 gs=0000 cr2=00000000 cr3=00000000 p=01 
005b:1d395615 8b5004         mov     edx,dword ptr [eax+04] ds:00000a11=invalid 
# k
005b:1d66a415 0326fb04 0326fb28 0326fb40 000007d0 [JVM __ZN7VMError6reportEP12outputStream + c95] 
005b:1d66ac75 0326fd10 0326fc74 000007d0 14d369a8 [JVM __ZN7VMError14report_and_dieEv + 175] 
005b:1d552b8f 0326fd10 20100800 c0000005 1d5a38d2 [JVM __Z23topLevelExceptionFilterP19_EXCEPTION_POINTERS@4 + df] 
005b:1d55605b 0326fdac 0326fe18 0326fe5c 20100800 [JVM __ZN2os20os_exception_wrapperEPFvP9JavaValueP12methodHandleP17JavaCallArgumP6ThreadES1_S3_S5_S7_ + 12b] 
005b:1d42831e 1d428550 0326ff30 0326fe18 0326fe5c [JVM __ZN9JavaCalls4callEP9JavaValue12methodHandleP17JavaCallArgumentsP6Thread +P6ThreadES1_S3_S5_S7_ + 12b] 
005b:1d433508 0326ff30 20100fcc 0326fe5c 20100800 [JVM __ZN12ResourceMark13reset_to_markEv$w$ZHmNp5XnJl615Smj4 + 248] 
005b:1d43d63b 0326ff04 20100800 331c45d8 03270eec [JVM _jni_CallStaticVoidMethod@0 + ab] 
005b:000119c4 20100918 20101ab8 202ffa18 20101aa8  
005b:1d94cd6e 0081fe0c 01081027 001b7128 0e4308ff [KERNEL32 _AsmCallThreadHandler + 56] 
005b:1d93af26 00000001 00010ad0 0081fe0c 009dfa88 [KERNEL32 Win32ThreadProc + 182] 
005b:1d87b36b 009dffe0 00000000 00000000 00000000 [WGSS50 threadWrapper + 257] 
005b:1ffece38 68000008  

This may be related to the generic SMP problem (#96).

[dmik]

It still crashes there. I performed some debugging and it looks like it crashes while walking the Java activation frames in order to print the Java call stack trace. A clear evidence of that is that the generated hs_err_*.log file ends with the following line:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

i.e. no Java call stack trace is printed, only its header.

[dmik]

Just as a note. In the recent state, the failed error reports are very rare. I don't get them on my machine at all any more but I see the truncated reports attached by reporters in the tickets from time to time.

[dmik]

These crashes now seem to happen when the reporter procedure tries to detect the flags for some memory address and access its contents. E.g.

• ​http://svn.netlabs.org/java/attachment/ticket/173/hs_err_pid207.log
• ​http://svn.netlabs.org/java/attachment/ticket/174/hs_err_pid169.log

We should review the respective part of the JVM code.