crashes after building from most recent sources

[John Rose]

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
>