Calling MemFree after an explicit destruction of the last context

[aiekick]

Hello,

i have a InputText Field, if i copy paste some data from the clipboard. when i call the app, after the ImGui::Shutdown(); the app crash here in imgui.cpp

i use your imgui_impl_sdl of example directory.

if i write something, there is no problem, but when i do ctrl+v, it crash (only when i close the app).
I dont know why this code is called after the ImGui:Shutdown(), and the callgraph of vs2015 on win7 give that

[ocornut]

Can you confirm that you are getting the bug when running the unmodified sample from the sdl_opengl2_example folder?

There's no code afaik that explicitly set GImGui to NULL.
EDIT Actually, DestroyContext may set GImGui to NULL if it is the current context, it is however not called by any example code.

[aiekick]

no it work, its weird, i have replace all the imgui and the interface with sdl2 from my app in the example and it work.
it may be a problem in my windows system..
i create a imgui context and i destroy it, maybe like you mention, it is due to that.

but im not sure why i created a context :), i find that in a sample on the net. what is the goal to create a imgui context ?

[aiekick]

it was for a multi windows system. how can i destroy the current context properly ? it is necessary ?

[ocornut]

Hmm.

Right now the easiest workaround is to never destroy the initial/default context.
You have memory (probably a static ImVector) allocated that's being free after the context is destroyed, it is a restriction that's inconvenient and undesirable. I'm not often running into it myself as I don't really use multiple context.

It's an issue with the design of storing those MemAllocFn MemFreeFn handlers in the context.
Perhaps they should just be global in the first place, as it is unlikely that people would need different allocator for different contexts (and even so, we could add a context pointer to the allocator function?).

I chose to put them in the context to avoid relying on #define which are less obvious to setup depending on your build system and/or how/if you compile dear imgui yourself.

I think I might just bite the bullet and move to global functions, aka GImGuiMalloc, GImGuiFree ?

Moving this discussion to #586

[aiekick]

for the moment, i not used the many context. and the bug appear only with the use of ctrl+v, so for the moment, i can wait a fix :) thanks, for the explains

[sonoro1234]

It is not happening for destroying default context, just destroying any context sets GImGui to NULL.

[MrSapps]

How come unmodified sample hasn't got this issue then?

[sonoro1234]

unmodified sample only uses default context

[zx64]

I've been running into a sporadic crash on shutdown in a Windows codebase that uses a non-default context. The code lives inside a DLL, so context lifetime is tied to when the DLL loads and unloads, but static variables are only destructed at process exit which happens after the DLL is unloaded...

The callstack points at the destructor for this variable:

static const char* GetClipboardTextFn_DefaultImpl(void*)
{
    static ImVector<char> buf_local;

I've locally changed it so it always uses a ImVector<char> that's tied to the current context:
ImVector<char>& buf_local = GImGui->PrivateClipboard;

I haven't done substantial testing to confirm if that fixes my problem, but does that seem like a reasonable change to make?

[ocornut]

@zx64 Well it would work but it is a little odd and misleading. That clipboard function should have nothing to do with an imgui context and you are using a buffer than happens to be lying in a context, so it ties the lifetime of the return value to the context. Practically speaking it is probably ok but it feels very misleading.

The code lives inside a DLL, so context lifetime is tied to when the DLL loads and unloads, but static variables are only destructed at process exit which happens after the DLL is unloaded...

If I understand correctly the problem is that at the time of destruction ImVector<> cannot access a destructor since it is stored in the current GImGui instance pointer?
Would my suggested changes in this message #586 (comment) solve the problem?

If that's the case you might also be able to temporarily workaround by restoring the default context after destroying your context.

(I suppose I should bite the bullet at some point and setup a DLL system to understand those problem better - I'm happy using Edit & Continue or Recode which doesn't requires DLL nor kill instances).

[zx64]

I think those changes would help - it'd avoid having ImVector's internal storage being allocated by one context and freed by another.
The asymmetric lifetime of function statics makes this especially awkward, hence my initial thought to remove needing to have a static variable - and there happened to be a buffer used by the non-Win32 default implementation of the clipboard.

[ocornut]

In spite of being a little odd, It wouldn’t hurt to implement your suggestion with an explicit comment to describe it. So I’m going to do that in the meanwhile as it is an easy change.

[ocornut]

@aiekick the changes described in #1565 should fix everything described in this issue.
You can now override the allocators with ImGui::SetAllocatorFunctions(), and they aren't stored in the context at all.

There's no default static/global context in imgui.cpp, only a pointer and you need to call CreateContext() to allocate a context.

If you have ImVector<> etc. destructed during program destruction when you'd want your allocators to be available during destruction as well.