Help with EXCEPTION_ACCESS_VIOLATION (0xc0000005)

843810

Hi,
I have started getting this error repeatedly and am unsure how to start deciphering it.

I am using JNI to C, but the fact that none of the threads in the log below appear to be in Native suggest presumably that the problem is not there(?)

It only happens when I am running multiple threads and initially I thought it was caused by running out of memory, but I trimmed the application down and called the garbage collector frequently and it still occurs.

The multiple threads are Runnable(s) submitted to an ExecutorService defined by Executors.newFixedThreadPool(5);
Each run it fails at a different stage, sometimes after a few minutes, sometimes after several hours, sometimes not at all.

Any tips on where to look would be appreciated.

A sample log file is:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000006dbe7a7f, pid=5184, tid=420
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.0-b13 mixed mode windows-amd64 )
# Problematic frame:
# V [jvm.dll+0x3f7a7f]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

--------------- T H R E A D ---------------

Current thread (0x0000000000508800): GCTaskThread [stack: 0x0000000006180000,0x0000000006280000] [id=420]

siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000019

Registers:
EAX=0x0000000000000001, EBX=0x0000000091035238, ECX=0x000000000051d810, EDX=0x0000000000000000
ESP=0x000000000627fc50, EBP=0x000000006dd580f0, ESI=0x000000000051d810, EDI=0x00000001631c8b88
EIP=0x000000006dbe7a7f, EFLAGS=0x0000000000010246

Top of Stack: (sp=0x000000000627fc50)
0x000000000627fc50: 00000001654101e8 0000000000000004
0x000000000627fc60: 000000000051d810 000000011b83f700
0x000000000627fc70: 00000001654bfd60 0000000000001000
0x000000000627fc80: 0000000000000000 000007fefdc8134c
0x000000000627fc90: 0000000000000000 0000000000508e01
0x000000000627fca0: 000000000000000c 000000000051d810
0x000000000627fcb0: 00000000089bed20 000000000051d810
0x000000000627fcc0: 000000006dd580f0 000000006dbe8ee8
0x000000000627fcd0: 0000000000000000 0000000000000009
0x000000000627fce0: 000000000627fd01 0000000091035238
0x000000000627fcf0: 0000000091035238 000000006db8c6ec
0x000000000627fd00: 0000000000509a00 000000000051d810
0x000000000627fd10: 0000000000000002 000000006db71020
0x000000000627fd20: 0000000000000014 000000000561affd
0x000000000627fd30: 0000000000000000 0000000000000020
0x000000000627fd40: 000000000627fda0 000000006dba5212

Instructions: (pc=0x000000006dbe7a7f)
0x000000006dbe7a6f: 48 d3 e0 48 03 05 5f c0 21 00 eb 04 48 8b 47 08
0x000000006dbe7a7f: 48 63 48 18 4c 8d 40 10 8b c1 c1 f8 03 85 c9 7f


Stack: [0x0000000006180000,0x0000000006280000], sp=0x000000000627fc50, free space=3ff0000000000000000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x3f7a7f]


--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x00000000089ca000 JavaThread "pool-1-thread-5" [_thread_blocked, id=2300, stack(0x0000000009d00000,0x0000000009e00000)]
0x00000000089c7800 JavaThread "pool-1-thread-4" [_thread_blocked, id=5372, stack(0x0000000009c00000,0x0000000009d00000)]
0x00000000089c7000 JavaThread "pool-1-thread-3" [_thread_blocked, id=6044, stack(0x0000000009b00000,0x0000000009c00000)]
0x0000000008aaa000 JavaThread "pool-1-thread-2" [_thread_blocked, id=1720, stack(0x0000000009a00000,0x0000000009b00000)]
0x0000000008c33800 JavaThread "pool-1-thread-1" [_thread_blocked, id=5784, stack(0x0000000009900000,0x0000000009a00000)]
0x0000000006f95000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5204, stack(0x0000000008660000,0x0000000008760000)]
0x0000000006f90800 JavaThread "CompilerThread1" daemon [_thread_blocked, id=4744, stack(0x0000000008560000,0x0000000008660000)]
0x0000000006f7b000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=912, stack(0x0000000008460000,0x0000000008560000)]
0x0000000006f7a000 JavaThread "Attach Listener" daemon [_thread_blocked, id=5524, stack(0x0000000008360000,0x0000000008460000)]
0x0000000006f79800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4488, stack(0x0000000008260000,0x0000000008360000)]
0x0000000006f1f000 JavaThread "Finalizer" daemon [_thread_blocked, id=5748, stack(0x0000000008160000,0x0000000008260000)]
0x0000000006f19000 JavaThread "Reference Handler" daemon [_thread_blocked, id=5968, stack(0x0000000008060000,0x0000000008160000)]
0x000000000022d000 JavaThread "main" [_thread_blocked, id=5760, stack(0x00000000023d0000,0x00000000024d0000)]

Other Threads:
0x0000000006f11800 VMThread [stack: 0x0000000007f60000,0x0000000008060000] [id=5312]
0x0000000006f96800 WatcherThread [stack: 0x0000000008760000,0x0000000008860000] [id=5656]

=>0x0000000000508800 (exited) GCTaskThread [stack: 0x0000000006180000,0x0000000006280000] [id=420]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x000000000022b020] Threads_lock - owner thread: 0x0000000006f11800
[0x000000000022b520] Heap_lock - owner thread: 0x00000000089c7800

Heap
PSYoungGen total 1212032K, used 1196384K [0x000000011b3f0000, 0x00000001663f0000, 0x00000001663f0000)
eden space 1195968K, 100% used [0x000000011b3f0000,0x00000001643e0000,0x00000001643e0000)
from space 16064K, 2% used [0x00000001643e0000,0x0000000164448000,0x0000000165390000)
to space 16384K, 5% used [0x00000001653f0000,0x00000001654ccaa0,0x00000001663f0000)
PSOldGen total 2457600K, used 199037K [0x00000000853f0000, 0x000000011b3f0000, 0x000000011b3f0000)
object space 2457600K, 8% used [0x00000000853f0000,0x000000009164f500,0x000000011b3f0000)
PSPermGen total 21248K, used 5514K [0x000000007fff0000, 0x00000000814b0000, 0x00000000853f0000)
object space 21248K, 25% used [0x000000007fff0000,0x0000000080552bc0,0x00000000814b0000)

843810

It may be premature to declare victory, but I read postings on other forums about a bug in the garbage collector of Update 18 of Java version 6 being unable to swallow large objects.

After replacing the JRE with update 20 it just completed the first successful multi-threaded run.

Keeping my fingers crossed.

jschellSomeoneStoleMyAlias

Roger123 wrote:
After replacing the JRE with update 20 it just completed the first successful multi-threaded run.

If you have a pointer bug and you change the environment then the impact of the bug can change.
Thus a buffer overflow in one case which causes the OS to fail your app, in another case that same overflow, due to a different execution path will not cause the OS to fail the app. But it doesn't mean that the pointer bug doesn't exist.

843810

Thanks for your words of wisdom.

Now after 6 successful runs with a variety of settings and no further failures, I am now prepared to declare victory.

That:
- my C code doesn't do very much behind the JVM's back (it is mostly a bridge to external library routines using memory allocated by Java)
- other people had the same problem with the same JRE version and also resolved it with a different version
...make me optimistic that it was a JVM bug.

Of course I can't rule out the possibility of a pointer bug and if the problem re-emerges I will bear your comments in mind.