It looks like you're new here. If you want to get involved, click one of these buttons!
GL_VERSION:4.6.0 - Build 27.20.100.9365 GLSL_VERSION:4.60 - Build 27.20.100.9365 *visit(EnterFrameEvent* v)* stack NOT ok begin:0 end:3 delta:0 *CppLuaBridge::luaEvent* stack NOT ok begin:0 end:3 delta:0 *enterFrame* stack NOT ok begin:0 end:3 delta:0 [6815] ../Common/imgui_src/imgui.cpp: font && font->IsLoaded() --this is the usual error I get on random crash in gideros player, but I only get this line. stack traceback: [string "dialogs.lua"]:490: in function drawGUI -- line 490 content is UI:newFrame(e.deltaTime) |
Comments
First I was using imgui and I thought that was the issue so I removed imgui from my app to use custom made buttons.
But the error persisted so imgui was not the cause
After some more research it turned out to be an issue with my path name:
- "gfx/adventurer-Sheet.png" -- error on win32 export
- "gfx\\adventurer-Sheet.png" -- error solved
So make sure ALL your paths are using \\ for win32.
Likes: pie
What I don't understand is why this happens random: I suppose that if it could not read paths it CAN NOT read them at all, not that sometimes it can, and sometimes can't, based on some planet alignment..
Likes: MoKaLux
- using imgui my app didn't crash at all I had the message *visit(EnterFrameEvent* v)* stack NOT ok begin:0 end:3 delta:0... in the win32 console
- after replacing imgui with my button class, the app crashed immediatly on launch AND the fix was to replace / with \\ for an image (I will try to reproduce it)
- the "faulty" line was located in EnterFrame
Maybe it has something to do with threading, for example in Qt export I could just call openFileDialog but in win32 export I have to call openFileDialog via asyncCall? ImGui may handle threading like Qt thus the random crashes on win32 export.
Likes: pie
While thinking about how // "seemed" to have fixed my problem I was using json.encode/decode (https://wiki.gideros.rocks/index.php/Examples#JSON_V2_.40mokalux) to write/read data from a text file (file_path, bg_color, ...).
@pie are you using json too?
EDIT: I cannot reproduce the bug at all when reverting to \ on win32
It seems so far that the crash happens only on windows (gideros player, win32 and Qt export) though.
thank you
If someone have a demo project that exhibits the issue, I can also try to debug it myself!
Likes: pie, MoKaLux
Likes: MoKaLux
I'm sorry I have one more question about this.
We have various imgui.dll in gideros folder: does this replace only the one in
\Templates\Qt\windowsdesktopTemplate\plugin
or could this be used to replace also the one that is used by gideros desktop player?
(I am not sure if it is the one in \Plugins or the one inside\All Plugins\imgui\bin -the file size seems to be the same).
I guess that for win32 we will have to wait for the next gideros release and it's totally fine.
I've never experienced the same crash on android yet, given that now you know what was the cause: do you think there is a chance it might happen there too?
thank you again
Likes: MoKaLux
And yes, the bug is platform independent, and could happen on android too
Likes: MoKaLux, pie
Likes: MoKaLux
Likes: pie, MoKaLux
Shall I just overwrite Gideros\All Plugins\imgui\bin\Android\ with the content of your file?
Likes: MoKaLux
Likes: MoKaLux, pie
This is the fix?
https://github.com/gideros/gideros/blob/881c45e282586ca28a5740d82ad1cf9d9a97b907/plugins/imgui/source/Common/imgui_bindings.cpp#L10437
Just use smart pointers?
Where did you find this information? I cant see anything like this in FAQ: https://github.com/ocornut/imgui/blob/master/docs/FONTS.md
From what I can tell, imgui copies configuration (including "ranges->Data" I guess?) to its own persistent storage here:
https://github.com/ocornut/imgui/blob/70cca1eac07aa3809bdd3717253c3754a5b7cfcc/imgui_draw.cpp#L2079
So, we can safely delete our "ranges" object?