ansaurus

Question

Java HotSpot error

Answer 1

A:

It's possible you ran out of memory. What are your -Xms -Xmx settings for the JVM? I'd suggest setting them to be the same. With the Hotspot JVM, I occasionally see crashes when it tries to increase the heap size.

It looks like your running a default sized JVM on Window (128MB). Avoiding Windows would help, but something else you can do is allocate more memory. Try setting your JVM to -Xms512m -Xmx512m
Setting the min and max memory ensures the heap is continuos and the JVM doesn't have to attempt to grow the heap. This leads to a more stable JVM.
The process died in jvm.dll. This is Sun's code, so they are the likely culprit, but is possible your external library corrupted the memory somewhere.
Your program is creating threads left, right, and centre. You can tell by the thread names. By default each thread gets a new sequentially numbered id. The program could reuse the threads by making use of a ThreadPool. The creation and collection of threads causes extra work for the JVM and OS.

brianegge 2009-11-19 23:19:57

Adjusting the memory settings apepared to do the trick, somehow we got narrow minded in that this was already done earlier when running as a service, however...in dev...cloudy viewpoint...forgot the simplest of things...thanks!

Aaron 2009-11-23 14:51:03

Answer 2

A:

When I get unexpected segmentation violations, my first suspect is a third-party DLL. I see that you have one there, from SysIntellect. Is it something that you need to run? If not, then take it out of your classpath, and see if you still get the problem.

The crash appeared to have been triggered by a thread currently running JVM code (see "_thread_in_vm" in the thread listing), so it's possible that you've stumbled across a VM bug (but more likely that you're seeing memory corrupted by that third-party DLL).

On the off chance that it was a VM bug, I did a search on the Sun Bug Parade, using the keywords "_thread_in_vm, jvm.dll+0xc8f23, 1.6.0_12-b04". No results returned, which indicates that either it's a rare bug or caused by outside interference. I mention the keywords because you'll generally see real bugs reporting the same PC ("jvm.dll+0xc8f23"), and it may be version-specific ("1.6.0_12-b04").

Good luck -- I've found that's the most helpful thing to say when faced with heap dumps.

Edit: you say that SysIntellect is your codebase, and it's clearly being loaded as a DLL, but in a comment above you say that you're not using JNI. In that case, how are you accessing the DLL?

If you can reproduce in a Linux environment, I'd recommend Valgrind to try to find any invalid accesses.

kdgregory 2009-11-20 13:18:41

The Syntellect component is our codebase...which is why narrowing in on who is responsible is critical...

Aaron 2009-11-20 14:54:34

ansaurus

tags:

views:

answers:

Java HotSpot error

related questions