[Octave-bug-tracker] [bug #55254] clear all crashes when variable from oct file class is displayed in workspace

[John W. Eaton]

Follow-up Comment #18, bug #55254 (project octave):

We can safely unload .oct files that contain simple functions when all the
functions are cleared.  But to unload a .oct file that defines and installs a
new octave_value type, we have to be sure that no references to the
dynamically created octave_value type remain and then unregister the
octave_value type.

After giving it a little more thought, I can see a way to do that.  It will

* Add the cost of a call to a virtual function to copying any octave_value
object.
* Require changing any dynamically loaded octave_value object to be derived
from a new base class that stores a reference to the shared library object
that contains the definition of the dynamically loaded octave_value object. 
This new base class will track all copies of the octave_value object and
attempt to unload the shared library object when the count goes to zero.

With these changes, I think reloading a .oct file that defines a new data type
would be possible provided that no copies of the dynamically loaded
octave_value object(s) exist when attempting to unload the .oct file.  If
there were, we should be able to emit an error message saying that values need
to be cleared first.  I don't think it will always be possible for Octave to
clear them automatically since devious users may store copies in ways that
Octave doesn't know about.

I think the type of crash reported here was avoided in the past because
normally, all copies of dynamically loaded octave_value objects were stored in
the symbol_scope object.  My change to pass a different "summary" symbol_info
object to the GUI instead of a symbol_scope object meant that other references
might exist that were not deleted before the shared library was unloaded. 
Going back to the way things were before is not an option because of the
pending changes to the way values are stored in the interpreter (see
http://lists.gnu.org/archive/html/octave-maintainers/2019-01/msg00042.html for
more info about that).

I'll see if I can come up with a draft patch to try.  Then we can decide
whether the change is worth doing, or whether we should just do something
simpler, like prohibiting unloading .oct files that create new octave_value
data types.


    _______________________________________________________

Reply to this item at:

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

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