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

[Jiangli Zhou]

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/.

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
>>
>