Maven : An unexpected error has been detected by HotSpot Virtual Machine

I was running a Maven2 build of a fairly large project when suddenly my VM said "An unexpected error has been detected by HotSpot Virtual Machine", keeled over, and died. Like a faithful Java programmer I ran the build again ... no luck! However, before it died, the VM wrote a log file. An ideal starting point for a post mortem, yet not much useful data. But I did notice an interesting line there ...
VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0805c388/0x0805c3b0] Threads_lock - owner thread: 0x08100b80
[0x0805c7d8/0x0805c7f0] Heap_lock - owner thread: 0x0805cf38
Looks like even the gods at Sun write Thread Unsafe code once in a while, not just us mere mortals. So I Googled around since Sun's explanation of this type of error was not very helpful. Apparently the Inet4AddressImpl of Sun isn't thread safe (or is it their IPV6 stack? see comments below), which is the root cause of this particular problem. The solution I came across was to use the VM option with Maven2.

My VM: Java HotSpot(TM) Server VM (1.5.0_16-b02) for linux-x86


Kosala Atapattu said…
I don't understand, if the IPv4 implementation is not thread safe, how can using the IPv4stack as a preference help the situation? Shouldn't you be preferring IPv6 instead?
Tyrell said…
Yes. I had the same question. But strangely, at least in my case, setting this property seems to work. Most probably the thread-safety issues are in their IPV6 stack. By default, if the OS supports it, the sockets made by the VM are IPV6.
emnu said…
anyway, how do we set this i have no idea. can you please show me. i'm using freebsd.
Tyrell said…
These can be passed as VM arguments when launching your application. For instance, for the Maven2 scenario described above, I now launch my maven build with;

mvn clean install

Popular posts from this blog

The Old Engineer and the Hammer

TechCrunch50 Conference 2008

An overnight success, 10 years in the making ....