[Octave-bug-tracker] [bug #58814] Abort, core dump on exiting from graphics code

[Markus Mützel]

Follow-up Comment #6, bug #58814 (project octave):

Sorry. I should at least have tried if the code compiles with the change.

I'm still not sure what exactly is going on. But I thought that (somehow) the
axes graphics object was destroyed while it was still being initialized.
I'm not sure if a copy-on-write approach would help in that particular case.
Wouldn't we have to pass a copy to the GUI thread independent of whether the
object might be changed? If the interpreter thread destroys the graphics
object before the GUI thread would have had a chance to make its copy, we
would see the same issue again, wouldn't we?
In that case, where would the clean-up be done? Would that mean that each
thread would need to clean-up their copy of the graphics object when it is
deleted?

If that can only happen when Octave closes, it is probably ok to keep the copy
of the object and let the OS do its job.
If this could also happen otherwise, I thought it would be ok to just skip the
remainder of the initialization. (That is what I was attempting with the
failing patch.)

I don't know what is done in which order when Octave closes. But to fix the
issue now: Should the GUI thread be unlocked (to finish whatever it has
started) before the interpreter destroys the gh_manager?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58814>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/