glfw backend crash

[huwpascoe]

Strange bug where holding a certain key and clicking causes exception.
g_PrevUserCallbackMousebutton is clobbered by an out of bounds write to g_KeyOwnerWindows.

imgui/backends/imgui_impl_glfw.cpp

Lines 116 to 119 in cbcd891

	if (action == GLFW_PRESS)
	io.KeysDown[key] = true;
	if (action == GLFW_RELEASE)
	io.KeysDown[key] = false;

Proposed fix:

    if(key >= 0 && key < IM_ARRAYSIZE(g_KeyOwnerWindows))
    {
        if (action == GLFW_PRESS)
        {
            io.KeysDown[key] = true;
            g_KeyOwnerWindows[key] = window;
        }
        if (action == GLFW_RELEASE)
        {
            io.KeysDown[key] = false;
            g_KeyOwnerWindows[key] = NULL;
        }
    }

[ocornut]

Hello,

Strange bug where holding a certain key

Which keys? What are the value of key ? Is key == -1 ?
Which Operating System and GLFW version?

[huwpascoe]

Yes, key is -1

In my keyboard's case, it's right shift

edit:
windows 10, docking branch

[ocornut]

That's absolutely very strange and surprising but I am going to add the bound check...

If you can compile GLFW yourself and set breakpoint in win32_window.c, function windowProc(), message WM_KEYDOWN` it would be interesting to see how it is possible that you get a value of -1 there.

createKeyTables() fills _glfw.win32.keycode[] with -1 default value so it mean your value of scancode in that function ends up not being setup in the keycode[] array. Would be good to investigate because maybe there is a bug to fix in GLFW.

What's your GLFW version?

[ocornut]

Pushed fix!
Would be helpful for us and GLFW if you can keep investigating the things discussed above and post your results.
Thank you very much!