JVM errors are mysterious and often difficult to reproduce, much less fix.

I've been getting some SIGSEGV from memcpy+0x1c JVM errors recently in long-running crawl processes, and in attempting to hunt down their cause, stumbled upon this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6366468

The interesting bit is here, from Thragor:

It seems I have found a way to reproduce this bug. It based on the assumption of dave_blake that it has something to do with a JAR being updated while being used.

I have two Hudson Jobs which may run in parallel. Let's call one the "producer" as it produces a JAR and the other one the "consumer" which depends on this JAR for a Maven Plugin to be called in generate-sources.

The producer provides a JAR which contains a file some.properties. The consumer uses a Maven Mojo which accesses this JAR through its classloader:

getClass().getClassLoader().getResources("META-INF/some.properties");

Now if you continuously build the producer project while the consumer project is build you will most likely get the failure as reported here.

I hope this is one additional indicator for how to reproduce this thing and perhaps finally find a solution for it.

My errors happened within Hudson too, but I'm fairly certain its not because of Hudson, but because, as Thragor suggests, the jars had been updated whilst being used.

Looking back, I do indeed see a correlation between my updating the jars and the JVM errors. It just hadn't occurred to me to put 2 and 2 together.

No Comments »