JVM access violation

[craigebevil]

I've only seen this once in months of using FlatLAF so it's not a blocker. Unfortunately, it's not possible to pin down exactly what was happening at the time, my application was in the midst of a complex MVC operation. The version of FlatLAF that I was using was version 1.2

Best wishes

Craige

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffbdb5614cc, pid=17016, tid=10532
#
# JRE version: OpenJDK Runtime Environment AdoptOpenJDK (11.0.8+10) (build 11.0.8+10)
# Java VM: OpenJDK 64-Bit Server VM AdoptOpenJDK (11.0.8+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# C  [flatlaf-windows-x86_64-59421262876000.dll+0x14cc]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# N:\ReleaseWorkspace\master\almasw\OBSPREP\ObservingTool\hs_err_pid17016.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.

hs_err_pid17016.log

[Bios-Marcel]

I've encountered this issue as well. I too couldn't pinpoint the problem. But it occurred right after updating to 1.4. Before that, we were on 1.0. So I'd say the major difference is the use of the embedded menu bar.

[craigebevil]

I was on 1.2 when the problem occurred.

…

On Tue, 20 Jul 2021 at 14:48, Marcel Schramm ***@***.***> wrote: I've encountered this issue as well. I too couldn't pinpoint the problem. But it occurred right after updating to 1.4. Before that, we were on 1.0. So I'd say the major difference is the use of the embedded menu bar. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#357 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZJ5ZATWHJCJGVMK44GYK3TYV5EJANCNFSM5ATRLN3A> .

-- *Craige Bevil* *UK ATC,* *Royal Observatory,* *Blackford Hill,* *Edinburgh,* *Midlothian,* *EH9 3HJ*

[DevCharly]

@craigebevil thanks for sharing the log. I'll hava a look...

@Bios-Marcel if you still have the log file (hs_err_pid....log),
could you please post it here or Email it to support@formdev.com?
Thanks.

[Bios-Marcel]

Yup, still have it, here you go:

hs_err_pid15328.log

FYI, I was using the theme Gradianto Nature Green at the time. I am unsure if it matters though.
The window was a maximized JFrame with an embedded menu bar.
This happened twice so far, both times when closing a dialog that had this frame as a parent.
During closing we usually save coordinates and size of the dialog, so getSize and getLocation are called on the dialog.
Not sure if any of that matters though.

[DevCharly]

Although the crash addresses in the two logs are different, the crash happens at the same code location.
Craige's log uses a slightly older DLL, but the disassembled code is the same at the two addresses.

Code in flatlaf-windows-x86_64.dll at address 1661 (disassembled using DUMPBIN):

  0000000180001661: 48 8B 4E 20        mov         rcx,qword ptr [rsi+20h]
  0000000180001665: 44 8B C3           mov         r8d,ebx
  0000000180001668: 4C 89 7C 24 20     mov         qword ptr [rsp+20h],r15
  000000018000166D: 4C 8B CF           mov         r9,rdi
  0000000180001670: 48 8B D5           mov         rdx,rbp
  0000000180001673: FF 15 47 1A 00 00  call        qword ptr [00000001800030C0h]
  0000000180001679: 48 8B 5C 24 60     mov         rbx,qword ptr [rsp+60h]
  000000018000167E: 48 8B 6C 24 68     mov         rbp,qword ptr [rsp+68h]
  0000000180001683: 48 8B 74 24 70     mov         rsi,qword ptr [rsp+70h]
  0000000180001688: 48 83 C4 40        add         rsp,40h
  000000018000168C: 41 5F              pop         r15
  000000018000168E: 41 5E              pop         r14
  0000000180001690: 5F                 pop         rdi
  0000000180001691: C3                 ret

Both logs report "access violation to address 0x20":

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000020

This matches the first instruction above. Register rsi is zero.

To find the source code for this, I've also disassembled FlatWndProc.obj (built with gradle) and searched for the first instruction. Found it at the end of C++ method FlatWndProc::WindowProc():

  0000000000000251: 48 8B 4E 20        mov         rcx,qword ptr [rsi+20h]
  0000000000000255: 44 8B C3           mov         r8d,ebx
  0000000000000258: 4C 89 7C 24 20     mov         qword ptr [rsp+20h],r15
  000000000000025D: 4C 8B CF           mov         r9,rdi
  0000000000000260: 48 8B D5           mov         rdx,rbp
  0000000000000263: FF 15 00 00 00 00  call        qword ptr [__imp_CallWindowProcA]
  0000000000000269: 48 8B 5C 24 60     mov         rbx,qword ptr [rsp+60h]
  000000000000026E: 48 8B 6C 24 68     mov         rbp,qword ptr [rsp+68h]
  0000000000000273: 48 8B 74 24 70     mov         rsi,qword ptr [rsp+70h]
  0000000000000278: 48 83 C4 40        add         rsp,40h
  000000000000027C: 41 5F              pop         r15
  000000000000027E: 41 5E              pop         r14
  0000000000000280: 5F                 pop         rdi
  0000000000000281: C3                 ret

This is the C++ line of the crashes:

FlatLaf/flatlaf-natives/flatlaf-natives-windows/src/main/cpp/FlatWndProc.cpp

Line 211 in 60e5861

return ::CallWindowProc( defaultWndProc, hwnd, uMsg, wParam, lParam );

mov rcx,qword ptr [rsi+20h] seems to load field FlatWndProc::defaultWndProc to register rcx, which is used to pass first parameter to method CallWindowProc (see x64 calling convention). Register rsi is used for C++ this in this method and is zero. The reason for this must be that the window proc is called with a unknown (probably destroyed) hwnd, then fwp becomes null and the app crashes.

FlatLaf/flatlaf-natives/flatlaf-natives-windows/src/main/cpp/FlatWndProc.cpp

Lines 178 to 179 in 60e5861

	FlatWndProc* fwp = (FlatWndProc*) hwndMap->get( hwnd );
	return fwp->WindowProc( hwnd, uMsg, wParam, lParam );

What window message was sent?
Since uMsg is passed as 3rd parameter to CallWindowProc(), it will be passed in register r8 (r8d is lower 32 bit of r8; see x64 Architecture), which is loaded at address 1665 with mov r8d,ebx. Register ebx is lower 32 bit of rbx.

rbx is zero in Craige's log, which is message WM_NULL.
In Marcel's log rbx is 0x00000000000002a2, which is message WM_NCMOUSELEAVE.

Anyway, was not able to reproduce a crash.
So will add a NULL check to avoid that crash.

[Bios-Marcel]

Thanks for the detailed explanation. I'll try reproducing it again. Maybe the error messages can lead me to what I did.

[DevCharly]

Fixed in main branch.

CC @ingokegel

[craigebevil]

Many thanks everybody. Regards Craige

…

On Sat, 31 Jul 2021 at 20:25, Karl T ***@***.***> wrote: Fixed in main branch. CC @ingokegel <https://github.com/ingokegel> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#357 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZJ5ZD2GKTFL3J6MBJ5Z43T2RE2FANCNFSM5ATRLN3A> .

-- *Craige Bevil* *UK ATC,* *Royal Observatory,* *Blackford Hill,* *Edinburgh,* *Midlothian,* *EH9 3HJ*

[Bios-Marcel]

Had no luck reproducing this. Tried all kinds of things with my mouse cursor that I could think of.