Imgui: Viewport resizing outside of main application window leads to crashes

Created on 26 Jun 2020 · 7Comments · Source: ocornut/imgui

Update after further testing (detailed in comments below): The issue seems to originate from Nahimic interacting with OpenGL. Disabling/uninstalling Nahimic solved the issue for me.

Dear ImGui 1.77 WIP (17602)
--------------------------------
sizeof(size_t): 4, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: _WIN32
define: _MSC_VER=1926
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000441
 NavEnableKeyboard
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigWindowsMemoryCompactTimer = 60.0f
io.BackendFlags: 0x0000140E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 RendererHasVtxOffset
 RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 1280.00,720.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Version/Branch of Dear ImGui:

Version: Dear ImGui 1.77 WIP (17602)
Branch: docking

Back-end/Renderer/Compiler/OS

Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp / imgui_impl_opengl2.cpp
Compiler: MSVC 1926
Operating System: Windows 10 64bit
Graphics card: RTX 2080 (Driver version 451.48)
Monitors: Two monitors (1080p60, 1440p144 w/ G-Sync)

DxDiag with more system information available here:
DxDiag.txt

My Issue:

When using viewport and draging an ImGui window out of the main application window and then resizing the viewport ImGui window a variable amount (intensity and time), the whole application suddenly crashes and throws an exception:

Exception thrown at 0x08B9F7A9 in example_glfw_opengl3.exe: 0xC0000005: Access violation reading location 0x0CC9F000.

(specific memory addresses vary from run to run)

With following callstack:

>   08b9f7a9()  Unknown
    [Frames below may be incorrect and/or missing]  Unknown
    nvoglv32.dll!0495d8d8() Unknown
    nvoglv32.dll!04be1ef8() Unknown
    nvoglv32.dll!0422cdb8() Unknown
    nvoglv32.dll!04be1eac() Unknown
    nvoglv32.dll!04215292() Unknown
    nvoglv32.dll!04215544() Unknown
    nvoglv32.dll!042159f4() Unknown
    nvoglv32.dll!04233db7() Unknown
    nvoglv32.dll!04234077() Unknown
    nvoglv32.dll!049625bc() Unknown
    nvoglv32.dll!041a3b80() Unknown
    nvoglv32.dll!04a03585() Unknown
    nvoglv32.dll!0420dedd() Unknown
    nvoglv32.dll!04a1ead9() Unknown
    nvoglv32.dll!04b60ee9() Unknown
    nvoglv32.dll!04bf1174() Unknown
    nvoglv32.dll!04922c69() Unknown
    nvoglv32.dll!04a0a00b() Unknown
    nvoglv32.dll!04a09d3f() Unknown
    nvoglv32.dll!04b7b022() Unknown
    kernel32.dll!764e6359() Unknown
    ntdll.dll!774d7c24()    Unknown
    ntdll.dll!774d7bf4()    Unknown

Visual Studio claims the current stack frame is not in module and therefore cannot show any source. This is an extract from the disassembly though:

[...]
0819F79A  mov         ecx,4  
0819F79F  jg          0819F7A9  
0819F7A5  neg         ecx  
0819F7A7  neg         ebp  
0819F7A9  mov         ebx,dword ptr [esi]     <- exception
0819F7AB  add         esi,ecx  
0819F7AD  add         edi,4  
0819F7B0  mov         eax,ebx  
0819F7B2  mov         edx,ebx  
0819F7B4  and         eax,0FF0000h  
[...]

Changing the thread to main thread in the debugger provides the following callstack:

    ntdll.dll!774e228c()    Unknown
    ntdll.dll![Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]   Unknown
    KernelBase.dll!7696c396()   Unknown
    opengl32.dll!7a404233() Unknown
    NahimicOSD.dll!6911bee7()   Unknown
    NahimicOSD.dll!69160b2e()   Unknown
    NahimicOSD.dll!6916057f()   Unknown
    NahimicOSD.dll!6911bfa2()   Unknown
    NahimicOSD.dll!6911938d()   Unknown
    gdi32full.dll!767819ab()    Unknown
    example_glfw_opengl3.exe!__glfwPlatformSwapBuffers
()  C
    example_glfw_opengl3.exe!_glfwSwapBuffers
()  C
>   example_glfw_opengl3.exe!ImGui_ImplGlfw_SwapBuffers(ImGuiViewport * viewport, void * __formal) Line 750 C++
    example_glfw_opengl3.exe!ImGui::RenderPlatformWindowsDefault(void * platform_render_arg, void * renderer_render_arg) Line 11592 C++
    example_glfw_opengl3.exe!main(int __formal, char * * __formal) Line 217 C++
    example_glfw_opengl3.exe!invoke_main() Line 78  C++
    example_glfw_opengl3.exe!__scrt_common_main_seh() Line 288  C++
    example_glfw_opengl3.exe!__scrt_common_main() Line 331  C++
    example_glfw_opengl3.exe!mainCRTStartup() Line 17   C++
    kernel32.dll!764e6359() Unknown
    ntdll.dll!774d7c24()    Unknown
    ntdll.dll!774d7bf4()    Unknown

Some more test scenarios

Issue persisted:

Tested in 32/64bits as well as debug/release modes, issue persisted through all of these.
Tested with varying degrees of content in the ImGui viewport window which possibly changed how long it took for it to crash, but issue still persisted
Tested checkout example but with Vsync OFF (glfwSwapInterval(0)) and the issue was still present

Issue seemingly was not present:

Tested with only one line of text in the ImGui viewport window and VSync OFF (glfwSwapInterval(0)) and the issue seemingly was not present
Tested on DirectX9-11 and issue was seemingly not present

Screenshots/Video

ImGuiViewPortResizeCrashStrippedDown

Additional more detailed videos:
These are on youtube as they were too large to host on GitHub

There are two videos, one shows the issue on a clean checkout version of example_glfw_opengl3 and the other shows it on a slightly lighter version with docking and extra windows and components disabled.

In both the videos I try to show how moving or resizing the ImGui window within the main application window does not present an issue, also moving the ImGui window outside the main application window also does not present an issue. It's only when resizing the ImGui window outside of the main application window that the issue shows itself.

Clean repo checkout: https://youtu.be/SCUHu8g2PnU

Stripped down: https://youtu.be/oYtw8yZ8eKQ

Standalone, minimal, complete and verifiable example:
Tested on clean checkout examples from docking branch, both example_glfw_opengl2 and example_glfw_opengl3. On these examples, disabling docking and using only a basic window with text on it still causes the issue.

Additional information
Asserts are turned on.

Here is an example of imgui.ini after a crash:

[Window][Debug##Default]
Pos=60,60
Size=400,400
Collapsed=0

[Window][Hello, world!]
ViewportPos=1657,416
ViewportId=0xEBE6C6E6
Size=361,391
Collapsed=0

[Window][Dear ImGui Demo]
Pos=26,73
Size=607,364
Collapsed=0

[Window][DockSpace Demo]
Size=1280,720
Collapsed=0

[Window][About Dear ImGui]
Pos=57,130
Size=569,442
Collapsed=0

[Docking][Data]

__(I tried providing as much information as I could regarding the issue, but this is also my first time submitting a report like this, so I apologize if I missed any important piece of information or if this issue already was known and I just didn't find it when I searched)__

backenbinding multi-viewports

Source

hesseb

👍2 ❤1

Most helpful comment

Hello,

I struggled with the same issue and thanks to you here finally it works. There's a Nahimic service, it seems to be enough to disable the service. I don't understand why Nahimic is in the call stack, there is nothing that requires audio.

In my case the ATI driver crashed, caused by NahmicOSD.dll

PS: It seems to be part of my sound software Sonic Studio with Realtek hardware.

larioteo on 5 Jul 2020

👍2

All 7 comments

Thank you Alex for such a careful and detailed report. This is likely going to be tricky to solve, but before I am able to attempt a repro (I’m not on my computer today), some early thoughts:

Instinctively I feel this is likely going to be an issue not linked to Dear ImGui. The inner loop of interacting with GLFW and OpenGL are pretty standards. I sense there’s a chance the answer won’t be something that we can action from the point of view of Dear ImGui’s examples/backends, but it would be worth investigating.

For completeness, here what I would do:

Try to repro with the SDL+OpenGL example in Dear ImGui repository.
Your callstack shows NahimicOSD.dll (on screen display for Nahimic). While I don’t have ample evidence outside of my use case, all of my personal experience with Nahimic led me to conclude it was buggy software. Anecdotally: I almost returned my current laptop after purchasing it, but it ended up being Nahimic severely breaking audio on the computer. May I suggest uninstalling it to see if whatever it is attempting to do with its OSD hook isn’t the cause of your crash.
I would try to update Nvidia drivers. Consider OpenGL is increasingly neglected by GPU drivers and fast resizing a GL framebuffer may lead to bugs.
I would try to repro the same thing without any Dear ImGui code. That is, by creating 2 or more GLFW windows and programatically resizing one every frame using GlfwSetWindowSize(). If the bug repo, that gives us a confirmation dear imgui isn’t really the cause.
Even if Dear ImGui isn’t the culprit and we want to chase that, know that depending on what else we find, it might be worth implementing some workaround on Dear ImGui’s backends side.

Again, those are thoughts in case you wanted to pursue this. I haven’t tried reproducing on my computer yet (will do), but also I don’t recall anyone reporting such crash in the past and I surely having seen it myself.

ocornut on 27 Jun 2020

❤1 👍1

I've done some more testing now and it seems, as you suspected, that the culprit was indeed Nahimic. After disabling it I haven't encountered the issue anymore. More specifically and for reference these are the tests I performed (all with the latest Nvidia driver installed):

I didn't test any minimal glfw or SDL-only examples as Nahimic seems to be the culprit together with OpenGL somehow. The easy way out is ofc to disable Nahimic, but considering it comes pre-installed on so many computers it would be nice if there was a workaround.

Either way, I believe this concludes the issue at least from my part. Thanks for the suggestions (:

Edit: I'm leaving the issue open in case you want to pursue it somehow, but otherwise feel free to close it.

hesseb on 27 Jun 2020

👍2

Hello,

In my case the ATI driver crashed, caused by NahmicOSD.dll

PS: It seems to be part of my sound software Sonic Studio with Realtek hardware.

larioteo on 5 Jul 2020

👍2

I've encountered the same problem but my call stack does not include Nahimic...

https://stackoverflow.com/questions/64128582/opengl-randomly-crashes-when-resizing-window-both-horizontally-and-vertically

The bug persist after updating drivers... I am writing a UI library and this begs the question - should I move from OpenGL to Direct3D? I need something stable.

thehorseisbrown on 30 Sep 2020

Hello @thehorseisbrown I think this is something you need to bring up with Nvidia.
Out of experience, DirectX tends to be better supported under Windows than OpenGL but pushing to get non-DX api supported well is essential. The same miiiight end up happening with Vulkan in a few years (and with ID Software now being owned by Microsoft it doesn't help either).

ocornut on 30 Sep 2020

Ok, I posted it on the Nvidia forum.

I'm ditching Opengl for good tho :D this is the last drop. I really don't like smart pointers and interfaces but hopefully I get some good stability with D3D.

It seems like 3rd party APIs should always be less likely to provide superior or equal stability. They don't have the money or the negotiating powers. But I agree that designing new APIs is a good thing. It would be awesome if GPU vendors had the upper hand and just put out new low level APIs whenever they wished and be like, hey have fun, you can do new cool things, write an API to your liking. There might be security issues with that tho.

thehorseisbrown on 30 Sep 2020

I'm closing this as "random stuff we can't seem to be able to fix on our side", however