But gcf.delete sometimes causes a crash. It was difficult to find the root cause.
Finally I found it.
It happened when the "ans" variable was present, referring to an object part of the figure being closed.
- During the gcf.delete call, the object ans refers to is destroyed
- The "de-referencing" of ans involves, 1) clearing ans (making it null) and 2) erasing ans from GOVars, which takes place in AstSIg::SetVar called from xcom::echo
But inside SetVar,
jt = GOvars.find(name);
The problem is, the iterator jt, return of the find call, may lose its validity when it is used (for example in the case of a simple use, if (jt == GOvars.end())), if GOvars changed in another thread. This can be easily demonstrated when the line to make jt and the line to use it are separated in SetVar, but even if they appear on the subsequent lines, it can happen.
Specifically, GOvars changes inside CShowvarDlg::OnPlotDlgDestroyed (in the shovar thread) and SetVar runs in the WinMain thread
In order to solve this problem, threads should be synchronized carefully and this conflict can be avoided.
However, an easier solution is, clear the ans variable and erase it from GOvars when entering the delete call, don't worry about ans during the call.
How? Call _delete_ans in Auxtra.cpp