Thanks for this analysis. We're all stuck with OpenJDK 1.7 build for now (32/64 bits build) :(
2011/3/16 John Rose <john.r.r...@oracle.com>: > I've been looking at this today. The JVM_ArrayCopy bug appears in amd64 with > UseCompressedOops turned on (the default). The problem appears to be a > trashed _klass field in the array for a source string (which happens to be > "main", suggesting an early demise). > > If you add -XX:-UseCompressedOops, you get a SEGV error outside of > JVM_ArrayCopy and in resource_allocate_bytes instead. In fact, I get the > same error in resource_allocate_bytes in both 32-bit and 64-bit builds. This > routine is a low-level allocator which picks up Thread::current() and > allocates bytes from a buffer on the current thread. (The bytes are scoped > inside the dynamic extent of a ResourceMark, and are usually treated as > thread-local.) > > In 32 bits (x86 not amd64), the immediate cause of the > resource_allocate_bytes failure is unexpected NULL contents in the _sp_map > array (used in threadLS_bsd_x86.cpp). If I put a print statement in > pd_set_thread I see that one or two threads declare themselves in an orderly > way. If I put a print statement in resource_allocate_bytes I see that many > successful allocations are done, with the _sp_map array apparently set > correctly, since the allocations succeed. Eventually an allocation comes > along and the _sp_map has been cleared (totally, as it happens). The > allocation logic tries to use NULL as the Thread::current() value and gets a > SEGV. > > In 64 bits (amd64), the logic for getting Thread::current() is totally > different; it uses [dyld_stub_]pthread_getspecific. In this case, a garbage > value is getting returned from pthread_getspecific. (See os_bsd.inline.hpp.) > > I have no idea why pthread_getspecific would return garbage on 64 bits, and > why _sp_map would be completely clear on 32 bits. > > Maybe it's just me, but since I haven't seen an update of the sources, > perhaps other people are still struggling with the same problem. > > This page has more information, including a transcript and a copy of the > error dump: > https://gist.github.com/872165 > > (BTW, -XX:+ShowMessageBoxOnError makes the JVM launch gdb before crashing.) > > Puzzled, > -- John > > On Mar 9, 2011, at 9:02 AM, Stephen Bannasch wrote: > >> I'm using soylatte16-i386-1.0.3 and have backed out all my changes and John >> Roses patches and am getting an abort trap after a >> seemingly successful build: >> >> testing build: ./build/bsd-amd64/j2sdk-image/bin/java -version >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00000001020ea915, pid=10411, tid=4298117120 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (21.0-b03 mixed mode bsd-amd64 >> compressed oops) >> # Problematic frame: >> # C [libjvm.dylib+0x463915] JVM_ArrayCopy+0x105 >> # >> # Failed to write core dump. Core dumps have been disabled. To enable core >> dumping, try "ulimit -c unlimited" before starting >> Java again >> # >> # An error report file with more information is saved as: >> # /Users/stephen/dev/java/src/bsd/hs_err_pid10411.log >> # >> # If you would like to submit a bug report, please visit: >> # http://java.sun.com/webapps/bugreport/crash.jsp >> # >> Abort trap >> >> More details here: https://gist.github.com/b6e70c49bf1ad8ed5e20 >> > > >
