<div dir="ltr"><div>Hi Alexandr,</div><div><br></div><div>my first guess would be what you also assumed, that registering code cache address ranges is flunky. Do you crash right away, or do other signals from code heap generally work (e.g. polling page faults)? Do the UNWIND information look correct? Have you confirmed that the addresses of the faulting instruction really lie within a registered UNWIND region?<br></div><div></div><div><br></div><div>Another possibility, albeit unlikely, is that in your build the outer __try/__except maybe does not work, or is missing?</div><div><br></div><div>Cheers, Thomas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 18, 2023 at 10:13 PM Alexandr Miloslavskiy <<a href="mailto:alexandr.miloslavskiy@syntevo.com">alexandr.miloslavskiy@syntevo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A single customer reports frequent crashes where hs_err_pid file is not <br>
created.<br>
<br>
The JDK is Zulu17.32+13-CA (build 17.0.2+8-LTS).<br>
<br>
We have studied Windows Event log and it indeed shows numerous crashes.<br>
We have then configured WER to capture a minidump and I studied it.<br>
<br>
The crash occurs in JIT generated code:<br>
----<br>
00000000`0e11f2c1 49ba401a3f93fd7f0000 mov r10,offset jvm+0x2d1a40 <br>
(00007ffd`933f1a40)<br>
00000000`0e11f2cb 41ffd2          call    r10<br>
00000000`0e11f2ce 6690            nop<br>
00000000`0e11f2d0 41b801000000    mov     r8d,1<br>
00000000`0e11f2d6 448b542424      mov     r10d,dword ptr [rsp+24h]<br>
00000000`0e11f2db 4183c230        add     r10d,30h<br>
00000000`0e11f2df 90              nop<br>
00000000`0e11f2e0 443b542428      cmp     r10d,dword ptr [rsp+28h]<br>
00000000`0e11f2e5 0f8d81160000    jge     00000000`0e12096c<br>
00000000`0e11f2eb 418bd8          mov     ebx,r8d<br>
00000000`0e11f2ee 448b5c2420      mov     r11d,dword ptr [rsp+20h]<br>
00000000`0e11f2f3 488b742458      mov     rsi,qword ptr [rsp+58h]<br>
00000000`0e11f2f8 8b4c2428        mov     ecx,dword ptr [rsp+28h]<br>
00000000`0e11f2fc 4c8b442460      mov     r8,qword ptr [rsp+60h]<br>
00000000`0e11f301 8bc3            mov     eax,ebx<br>
00000000`0e11f303 4c8b6c2468      mov     r13,qword ptr [rsp+68h]<br>
00000000`0e11f308 43807c131070    cmp     byte ptr [r11+r10+10h],70h<br>
00000000`0e11f30e 0f8471000000    je      00000000`0e11f385<br>
00000000`0e11f314 418b5e2c        mov     ebx,dword ptr [r14+2Ch]<br>
00000000`0e11f318 8b6b0c          mov     ebp,dword ptr [rbx+0Ch]<br>
00000000`0e11f31b 3bc5            cmp     eax,ebp<br>
00000000`0e11f31d 666690          nop<br>
00000000`0e11f320 0f85df0c0000    jne     00000000`0e120005<br>
00000000`0e11f326 4c8b4c2430      mov     r9,qword ptr [rsp+30h]<br>
00000000`0e11f32b 418b410c        mov     eax,dword ptr [r9+0Ch]<br>
----<br>
<br>
It crashes on this instruction:<br>
00000000`0e11f32b 418b410c        mov     eax,dword ptr [r9+0Ch]<br>
<br>
Because r9 is NULL. Looks like implicit null exception to me, which <br>
should have been handled by JVM.<br>
<br>
I have then investigated if JVM's crash handler is installed properly.<br>
In the minidump, the following can be seen in 'FunctionTableStream'<br>
* MinimumAddress=0000000005CD0000 MaximumAddress=0000000014CD0000 <br>
BaseAddress=0000000005CD0000<br>
* * BeginAddress=0000000000000000 EndAddress=000000000F000000 <br>
UnwindData=000000000000039C<br>
<br>
This looks like valid handler installed via 'os::register_code_area'. At <br>
least when I inspect 'os::register_code_area' on my machine, it <br>
registers very similar values.<br>
<br>
At this point, I think I need advice. What could go wrong in JVM so that <br>
it neither handles this exception nor crashes into hs_err_pid and <br>
instead lets Windows handle the crash?<br>
</blockquote></div>