RFR 8054008: Using -XX:-LazyBootClassLoader crashes with ACCESS_VIOLATION on Win 64bit

[Jiangli Zhou]

Ok. Thank you for confirming that!

Jiangli

On 11/11/2014 10:42 AM, Lois Foltan wrote:
>
> On 11/11/2014 1:30 PM, Jiangli Zhou wrote:
>> Hi Lois,
>>
>> Actually there was an updated webrev based on Roland's feedback. 
>> Since you are replying to the original request, not sure if you 
>> reviewed the latest webrev. If not, here is the link: 
>> http://cr.openjdk.java.net/~jiangli/8054008/webrev.02/.
>
> My apologies, I did review .02 but responded to your first RFR 
> request.  Looks fine.
> Lois
>
>>
>> Thanks,
>> Jiangli
>>
>> On 11/11/2014 10:22 AM, Lois Foltan wrote:
>>> Hi Jiangli,
>>> Yes, this looks good, reviewed.
>>> Lois
>>>
>>> On 11/6/2014 8:35 PM, 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
>>>>
>>>
>>
>