RFR(S): 7143038: SIGSEGV in assert_equal / LinearScan::assign_reg_num

[Tom Rodriguez]

Looks good.

tom

On Feb 15, 2012, at 1:50 AM, Roland Westrelin wrote:

> 
> glibc's exit is called through jvmti which triggers the call of destructors for global variables such as:
> LocationValue         _illegal_value = LocationValue(Location());
> 
> An example call stack:
> 
> #8  0x01056b7f in LocationValue::~LocationValue() (this=0x1a07470)
>   at /tmp/roland/hotspot/src/share/vm/ci/ciConstant.hpp:73
> #9  0x01039b42 in __tcf_5 ()
>   at /tmp/roland/hotspot/src/share/vm/c1/c1_LinearScan.cpp:2472
> #10 0x007ca209 in exit () from /lib/i686/nosegneg/libc.so.6
> #11 0x0011f6c2 in forceExit (exit_code=15)
>   at ../../../src/share/back/debugInit.c:635
> #12 0x0011c7e8 in doExit (in=0x8d549edc, out=0x8d549d7c)
>   at ../../../src/share/back/VirtualMachineImpl.c:624
> #13 0x00122643 in debugLoop_run () at ../../../src/share/back/debugLoop.c:172
> #14 0x00136d8f in connectionInitiated (t=0x485e50)
>   at ../../../src/share/back/transport.c:261
> #15 0x00136dd0 in attachThread (jvmti_env=0x830dc1c, jni_env=0x84a2940,
>   arg=0x485e50) at ../../../src/share/back/transport.c:334
> #16 0x0141c1fb in JvmtiAgentThread::call_start_function (this=0x84a2800)
>   at /tmp/roland/hotspot/src/share/vm/prims/jvmtiImpl.cpp:90
> #17 0x0141c2ad in JvmtiAgentThread::start_function_wrapper (thread=0x84a2800,
>   __the_thread__=0x84a2800)
>   at /tmp/roland/hotspot/src/share/vm/prims/jvmtiImpl.cpp:84
> #18 0x016811b7 in JavaThread::thread_main_inner() ()
>   at /tmp/roland/hotspot/src/share/vm/runtime/thread.cpp:1546
> #19 0x01683cfb in JavaThread::run (this=0x84a2800)
>   at /tmp/roland/hotspot/src/share/vm/runtime/thread.cpp:1523
> #20 0x0154c7fb in java_start (thread=0x84a2800)
>   at /tmp/roland/hotspot/src/os/linux/vm/os_linux.cpp:887
> #21 0x00933869 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
> #22 0x0087213e in clone () from /lib/i686/nosegneg/libc.so.6
> 
> The virtual table pointers of the C++ objects are updated to the one of ResourceObj. A compilation may still be in progress at the same time and perform a virtual call on one of the global objects, leading to a call to an erroneous address and a crash.
> 
> http://cr.openjdk.java.net/~roland/7143038/webrev/