Re: octave-3.0.0+ segmentation fault

[Michael Goffioul]

On 1/5/08, John W. Eaton <address@hidden> wrote:
> If we can't have the octave_dld_function destructor also unload the
> shared library, then with the current design we need to defer
> unloading the shared library until it is safe to do so.  Perhaps by
> putting it on a list of libraries to unload and then periodically
> calling a function to unload the shared libraries that appear in the
> list (for example, just before the next .oct or .mex file is loaded).
>
> I think this could be handled fairly cleanly within the in
> octave_dynamic_loader class in src/dynamic-ld.cc.  Instead of having
> octave_dynamic_loader::do_remove actually unload the shared library,
> it should just place the library on a list (can probably be a member
> of the octave_dynamic_loader class) to be cleared.  Then modify
> octave_dynamic_loader::do_load_oct and
> octave_dynamic_loader::do_load_mex to each call a new function to
> actually unooad the files that appear in the list before they do
> anything else.
>
> Sorry, but I don't have time at the moment to make this change.  I
> might be able to look at it on Monday.
>
> Just as a quick check to see if this might avoid the crash, what
> happens if you change
>
>  octave_dld_function::~octave_dld_function (void)
>  {
>    octave_dynamic_loader::remove (my_name, sh_lib);
>  }
>
> to
>
>  octave_dld_function::~octave_dld_function (void) { }
>
> in src/ov-dld-fcn.h?

This indeed avoids the crash. Basically, the fundamental problem is that
when an oct-file is loaded by octave, it creates an octave_dld_function
object (through new DEFUN_DLD expansion). This octave_dld_function is
such that, when deleted, the oct-file file will be unloaded from memory.
This seems to be a problem, because MSVC will attach to the created
object some auto-generated deletion-code (used to handle virtual destructors,
since at least VC++ 2) that will be executed in the oct-file address space
(I guess this is due to the fact that the object is created by the oct-file).
And because deleting the octave_dld_function unloads the oct-file, this
unvalidates the call stack.

So, in summary, I think that another possible solution would be to avoid
to create the octave_dld_function in the oct-file, such that the corresponding
virtual destructor code will not be executed in the oct-file address space.
This used to be the case before the object-branch merge, but I don't know
whether this is still feasible...

Michael.