Giters

CedricGuillemet / ImGuizmo

Immediate mode 3D gizmo for scene editing and other controls based on Dear Imgui

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Assertion fails for ImVector::operator[](int)

Khhs167 opened this issue · comments

commented

Hi!

I've been trying to use ImGuizmo for my project for quite some time now, and I keep on running into an assertion error in ImGui whenever ImGuizmo.BeginFrame(); is invoked.

I can't really figure out where to stick the error so here it is:
T& ImVector<T>::operator[](int) [with T = ImGuiViewportP*]: Assertion 'i >= 0 && i < Size' failed.

I don't get an error stack and I'm unsure if I can get one since I'm running C#.

ImGuizmo.BeginFrame is being invoked just after my ImGui backend invokes ImGui.NewFrame.

Please tell me if there's any more information needed :)

commented

Managed to figure out GDB and narrowed it down to ImGui::GetMainViewport() being called within ImGuizmo::BeginFrame(). Time to figure out why that's asserting.

commented

Seems to be an issue with the ImGuiContext having a 0-size Viewports array(or so I'd assume, since 0-indexing should only fail if the size is 0). Might have to move the issue to the main ImGui repo unless I'm missing something

commented

Seems as if I call ImGui.GetMainViewport() from managed code it works without a hitch, and the managed code just calls down into ImGui::GetMainViewport so it's not an issue with ImGui from what I can tell. Reading into the code I'm not even able to find a trace of ImGui::GetMainViewport so I'm getting fairly confused now.

EDIT: Oh wait, it's there, in the ImGui::SetNextWindowSize stuff. Could it be a mismatch in context versions or something? Context should be working properly. I'll try to rebuild with IMGUI_HAS_VIEWPORT forced to be undefined

commented

Figured out I never actually replaced the binaries(due to how .NET prioritizes .so files), so now it's instead a SIGSEGV in ImGui::PushStyleColor/ImVector::push_back. We'll see how this goes heh.

commented

All right, so I recompiled and linked cimguizmo and cimgui to the same ImGui binary, and managed to figure out a bit more using lldb. ImGui and ImGuizmo are using a context located at the same location, but for whatever reason it looks to be corrupt by the time ImGuizmo gets around to actually using it, which is where the issue comes from.

Strange...

commented

I didn't really want to share binaries since copyright stuff makes it all complex, and there are a lot of test assets that I don't directly own, but I thought that sending binaries might just help(once this issue is resolved I'll delete the files from drive just to be sure)

https://drive.google.com/file/d/1Pklyyt6bdxtdKWKvxZUy1EBq1FgvByjs/view?usp=sharing

Oh and it's another, even stranger issue occuring in these binaries(a segfault out of nowhere? In the middle of a function?)

commented

They might be compiling with different ideas of what an ImGuiContext is?

I am incredibly confused and would greatly appreciate some help

(lldb) expression ((ImGuiContext*)0x0000555555b1ea50)->Viewports
(ImVector<ImGuiViewportP *>) $5 = {
  Size = 1
  Capacity = 8
  Data = 0x0000555555b26aa0
}
(lldb) expression ((ImGuiContext*)GImGui)->Viewports
(ImVector<ImGuiViewportP *>) $6 = {
  Size = 1
  Capacity = 8
  Data = 0x0000555555b26aa0
}
(lldb) expression GImGui->Viewports
(ImVector<ImGuiViewportP *>) $7 = {
  Size = 0
  Capacity = 0
  Data = nullptr
}
(lldb) frame variable GImGui
(ImGuiContext *) ::GImGui = 0x0000555555b1ea50
(lldb) expression  GImGui == 0x0000555555b1ea50
(bool) $8 = true

Going slowly insane lol

commented

I haven't been able to fully test it yet, but I finally got it to at least run!

What I had to do was to change the following lines in imgui_internal.h from

#ifndef IMGUI_DISABLE_OBSOLETE_KEYIO
        ActiveIdUsingNavInputMask = 0x00;
#endif

to

        ActiveIdUsingNavInputMask = 0x00;

So seems like it was just a silly compiler flag lol.

Happy to have this resolved!