crashes after building from most recent sources

[Henri Gomez]

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.rose at 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
>>
>
>
>