octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #61994] Crash on GUI exiting with octave_base_


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #61994] Crash on GUI exiting with octave_base_value objects still open.
Date: Wed, 16 Feb 2022 22:51:23 -0500 (EST)

Follow-up Comment #24, bug #61994 (project octave):

By adding a delay in the workspace_model::set_workspace function I was able to
observe the crash with both the old and new terminal widgets.  The issue is
that if the interpreter::shutdown actions finish before the workspace model is
cleared, then it is possible for shared libraries like audiodevinfo.oct to be
closed before all symbols created by them are deleted.  The audiodevinfo.oct
file defines the audioplayer class, so attempting to call the destructor for
an object of that class after the shared library has been closed results in a
crash.

My attempts to fix this haven't necessarily been the wrong thing to do, but
they are not getting at the real problem here.

I see a few options:

0 Wait for the GUI to close before the interpreter clears all symbols and
unloads shared libraries.  This is somewhat difficult to do with the current
terminal/interpreter design and would require some refactoring even with the
experimental terminal.
0 Ensure that shared libraries that define classes aren't unloaded before all
instances of the classes that they define are deleted.  How?
0 Avoid calling the dynamic_library destructor (see oct-shlib.h) during the
shutdown procedure.  Note that mlock is not enough (we already do that for the
DLD functions defined in audiodevinfo.oct).  We override mlock by forcing
symbols to be cleared near the end of interpreter::shutdown and even if we
skip that, destructors for the dynamic library objects will eventually be
deleted when the destructors are called for the symbol and function tables.

I'm not sure what the best long-term option is, but I'm leaning toward the
third option as the best thing to do in the short term for the release.
also caused the

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]