Other Threads: 0x0023f798 VMThread [id=3092] 0x2ad6df70 WatcherThread [id=3040]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap def new generation total 7232K, used 2056K [0x02980000, 0x03150000, 0x050e0000) eden space 6464K, 25% used [0x02980000, 0x02b1abe0, 0x02fd0000) from space 768K, 53% used [0x03090000, 0x030f76b0, 0x03150000) to space 768K, 0% used [0x02fd0000, 0x02fd0000, 0x03090000) tenured generation total 87004K, used 53177K [0x050e0000, 0x0a5d7000, 0x22980000) the space 87004K, 61% used [0x050e0000, 0x084ce780, 0x084ce800, 0x0a5d7000) compacting perm gen total 78336K, used 78196K [0x22980000, 0x27600000, 0x2a980000) the space 78336K, 99% used [0x22980000, 0x275dd0e0, 0x275dd200, 0x27600000) No shared spaces configured.
Originally posted by ravi naik: # # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x77f8910e, pid=3084, tid=2148 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode) # Problematic frame: # C [ntdll.dll+0x910e] #
Usually this is caused by referencing a piece of memory in a native method that hasn't been initialized yet or has already been freed.
Is this in native code you have written, or is it in a third party DLL? If it is the first, you'll have to check where the problem is in your native code. Printing debug information usually helps me. If it is a third party DLL then first check if you aren't violating the contract of its API (like passing null where it isn't allowed). If you don't, contact the creators.
Looks like it's the JDBC/ODBC bridge, which is simply not meant for production work. It's a buggy mess. What you need to do it to obtain the real driver for your database. If your database is Access, then you need to use a real database for an application that's serving this many clients!