RFR 8054008: Using -XX:-LazyBootClassLoader crashes with ACCESS_VIOLATION on Win 64bit
Jiangli Zhou
jiangli.zhou at oracle.com
Fri Nov 7 17:11:07 UTC 2014
Thank you, David. I see Roland has some suggestions regarding the
change. I'll explore those.
Thanks,
Jiangli
On 11/06/2014 10:40 PM, David Holmes wrote:
> On 7/11/2014 4:26 PM, David Holmes wrote:
>> Looks good to me! Glad to see this could be resolved with changing the
>> initialization sequence!
>
> s/with/without/ :)
>
> David
>
>>
>> Please update copyright year before pushing.
>>
>> Thanks,
>> David
>>
>> On 7/11/2014 11:35 AM, Jiangli Zhou wrote:
>>> Hi,
>>>
>>> Please review the following changes that fix the crash with
>>> -XX:-LazyBootClassLoader on windows x64 platforms (fastdebug only).
>>> During VM initialization, current_stack_pointer() could be called
>>> before the VM generates stub routines. The generated get_previous_sp
>>> routine cannot be used during that time, use the estimated value for
>>> the
>>> sp value instead. The x86 implementation is unaffected by the change
>>> and
>>> always returns the estimated sp value as before.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054008
>>> webrev: http://cr.openjdk.java.net/~jiangli/8054008/webrev/
>>>
>>> Tested with JPRT and ExtBadJAR test.
>>>
>>> Background:
>>> As part of the VM initialization, classLoader_init() calls ZIP_Open
>>> from
>>> the zip library for processing the boot class path when
>>> -XX:-LazyBootClassLoader is specified. The call path re-enters VM
>>> before
>>> returning from the zip library call. Following is the backtrace right
>>> before when the crash happens. The windows x64 version of
>>> current_stack_pointer() uses generated stub routine get_previous_sp
>>> (generated by generate_get_previous_sp()) to obtain the stack pointer
>>> value. Since classLoader_init() happens before stubRoutines_init1() and
>>> the stub routines are not generated at the time, the execution jumps to
>>> address 0 (referenced by _get_previous_sp_entry which should contain
>>> the
>>> address of the generated routine after stubRoutines_init1()) when it's
>>> trying to call the stub routine and crashes.
>>>
>>>
>>> jvm.dll!os::current_stack_pointer() Line 468 C++
>>> jvm.dll!os::verify_stack_alignment() Line 638 + 0x5 bytes C++
>>> jvm.dll!JVM_NativePath(char * path) Line 691 C++
>>> zip.dll!000007feebc49de0()
>>> [Frames below may be incorrect and/or missing, no symbols loaded
>>> for zip.dll]
>>> zip.dll!000007feebc4af1d()
>>> zip.dll!000007feebc4b004()
>>> jvm.dll!ClassLoader::create_class_path_entry(const char * path,
>>> const stat * st, bool lazy, bool throw_exception, Thread *
>>> __the_thread__) Line 666 + 0x13 bytes C++
>>> jvm.dll!ClassLoader::update_class_path_entry_list(const char *
>>> path, bool check_for_duplicates, bool throw_exception) Line 763 + 0x2d
>>> bytes C++
>>> jvm.dll!ClassLoader::setup_search_path(const char * class_path)
>>> Line 630 C++
>>> jvm.dll!ClassLoader::setup_bootstrap_search_path() Line 594 C++
>>> jvm.dll!ClassLoader::initialize() Line 1237 C++
>>> jvm.dll!classLoader_init() Line 1291 C++
>>> jvm.dll!init_globals() Line 100 C++
>>> jvm.dll!Threads::create_vm(JavaVMInitArgs * args, bool *
>>> canTryAgain) Line 3414 + 0x5 bytes C++
>>> jvm.dll!JNI_CreateJavaVM(JavaVM_ * * vm, void * * penv, void *
>>> args) Line 5199 + 0x12 bytes C++
>>> java.exe!000000013f0520f6()
>>> java.exe!000000013f05cb63()
>>> java.exe!000000013f05cbf7()
>>> kernel32.dll!0000000076ba59ed()
>>> ntdll.dll!0000000076cdc541()
>>>
>>> Thanks,
>>> Jiangli
>>>
More information about the hotspot-runtime-dev
mailing list