RFR: 8309613: [Windows] hs_err files sometimes miss information about the code containing the error

[Martin Doerr]

On Thu, 8 Jun 2023 02:10:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We have seen hs_err files for errors triggered by C2 compiled methods which miss the most relevant information: the C2 method (see JBS issue for more details). I have found a possibility to add it. Please take a look and provide feedback.
>> 
>> Testing:
>> 
>> diff --git a/src/hotspot/share/opto/parse1.cpp b/src/hotspot/share/opto/parse1.cpp
>> index f179d3ba88d..c35a1ac595e 100644
>> --- a/src/hotspot/share/opto/parse1.cpp
>> +++ b/src/hotspot/share/opto/parse1.cpp
>> @@ -1210,6 +1210,12 @@ void Parse::do_method_entry() {
>>      make_dtrace_method_entry(method());
>>    }
>>  
>> +  if (UseNewCode) {
>> +    Node* halt = _gvn.transform(new HaltNode(control(), frameptr(), "Requested Halt!"));
>> +    C->root()->add_req(halt);
>> +    set_control(halt);
>> +  }
>> +
>>  #ifdef ASSERT
>>    // Narrow receiver type when it is too broad for the method being parsed.
>>    if (!method()->is_static()) {
>> 
>> 
>> "java -XX:+UseNewCode -version" shows the following output (when no hsdis lib is provided):
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [jvm.dll+0x6ca5b9]  os::win32::platform_print_native_stack+0xd9  (os_windows_x86.cpp:236)
>> V  [jvm.dll+0x8a3afa]  VMError::report+0xd6a  (vmError.cpp:973)
>> V  [jvm.dll+0x8a5cde]  VMError::report_and_die+0x5fe  (vmError.cpp:1765)
>> V  [jvm.dll+0x283061]  report_fatal+0x71  (debug.cpp:212)
>> V  [jvm.dll+0x621c3e]  MacroAssembler::debug64+0x8e  (macroAssembler_x86.cpp:829)
>> C  0x000001635fe021f4
>> 
>> 
>> called by the following code:
>> Compiled method (c2)      87   16       4       java.lang.Object::<init> (1 bytes)
>>  total in heap  [0x000001635fe02010,0x000001635fe02250] = 576
>>  relocation     [0x000001635fe02170,0x000001635fe02188] = 24
>>  main code      [0x000001635fe021a0,0x000001635fe02200] = 96
>>  stub code      [0x000001635fe02200,0x000001635fe02218] = 24
>>  metadata       [0x000001635fe02218,0x000001635fe02220] = 8
>>  scopes data    [0x000001635fe02220,0x000001635fe02228] = 8
>>  scopes pcs     [0x000001635fe02228,0x000001635fe02248] = 32
>>  dependencies   [0x000001635fe02248,0x000001635fe02250] = 8
>> 
>> [Constant Pool (empty)]
>> 
>> [MachCode]
>> [Entry Point]
>>   # {method} {0x0000000800478d78} '<init>' '()V' in 'java/lang/Object'
>>   #           [sp+0x20]  (sp of caller)
>>   0x000001635fe021a0: 448b 5208 | 49bb 0000 | 0000 0800 | 0000 4d03 | d349 3bc2 
>> 
>>   0x000001635fe021b4: ;   {runtime_call ic_miss_stub}
>>   0x000001635fe021b4: 0f85 c6c4 | 8fff 6690 | 0f1f 4000 
>> [Verified Ent...
>
> src/hotspot/share/utilities/vmError.cpp line 680:
> 
>> 678:   // keep track of which code has already been printed
>> 679:   const int printed_capacity = max_error_log_print_code;
>> 680:   address printed[printed_capacity];
> 
> Does this buffer get reused/overwritten by the "printing code blobs" logic?

The purpose of the buffer is to keep track of what has already been printed. We don't want to print the same code again if we encounter the address again. This can be used across several error reporting steps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14358#discussion_r1222716743