Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Careful when using ImGuiTextFilter with multiple instances. #833

Closed
aegagros opened this issue Sep 16, 2016 · 4 comments
Closed

Careful when using ImGuiTextFilter with multiple instances. #833

aegagros opened this issue Sep 16, 2016 · 4 comments

Comments

@aegagros
Copy link

ImGui::MemFree depends on the currently active context, therefore when using ImGui::CreateContext() and ImGui::DestroyContext() make sure not to destroy the active context before any ImGuiTextFilter objects are destroyed. Situation gets more complex if the filter objects are static as in the examples.

This is due to the dependency of ImGui::MemFree() to the currently active context (GImGui variable), so it may apply to other heap-allocated objects that I am not aware of.

Maybe relates to #591; didn't want to open a new issue for a warning but I thought I should share it with people, since it took me a few hours to determine why my application was segfaulting upon shutdown.

@ocornut
Copy link
Owner

ocornut commented Sep 23, 2016

Hello,

Not super happy with the fact that malloc/free funcs are stored in the context. It gives more flexibility but makes that sort of situation confusing. Last time I re-evaluated this ( for #586 (comment) ) I kept it in the context.

It would perhaps make more sense to move them to static globals ? I don't know.

Do you have a suggestion?

@MrSapps
Copy link

MrSapps commented Sep 23, 2016

Why not have a debug-only global static flag that asserts if you try to access these functions after the context is destroyed? It would make sense all the user destroys all im gui objects before the context anyways? :s

@aegagros
Copy link
Author

Hi again,

I was referring to the fact that the default alloc/dealloc functions use a counter to track currently active allocations, stored in the currently active context (ImGuiIO::MetricsAllocs). I'm not sure if this is used elsewhere, except to report how many active allocations there are. Maybe consider removing?

Regarding the storage of the custom malloc/free functions inside the context, IMHO the best place is the currently active context as you have already implemented; both from a design perspective (contexts should be kept as self-contained as possible) and from a multithreaded perspective (imagine having a different imgui context from different threads).

By the way, since its my first issue/post, great job with the library Omar! Thank you! 👍

@ocornut
Copy link
Owner

ocornut commented May 2, 2018

Closing this old issue as the problem was solved by #1565, MemFree etc. are not context dependant.

@ocornut ocornut closed this as completed May 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants