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 >
