[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: octave-3.0.0+ segmentation fault
From: |
Michael Goffioul |
Subject: |
Re: octave-3.0.0+ segmentation fault |
Date: |
Sat, 5 Jan 2008 22:52:44 +0100 |
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.
- octave-3.0.0+ segmentation fault, John W. Eaton, 2008/01/04
- Re: octave-3.0.0+ segmentation fault, Michael Goffioul, 2008/01/04
- Re: octave-3.0.0+ segmentation fault, John W. Eaton, 2008/01/04
- Re: octave-3.0.0+ segmentation fault, Michael Goffioul, 2008/01/05
- Re: octave-3.0.0+ segmentation fault, Michael Goffioul, 2008/01/05
- Re: octave-3.0.0+ segmentation fault, John W. Eaton, 2008/01/05
- Re: octave-3.0.0+ segmentation fault,
Michael Goffioul <=
- Re: octave-3.0.0+ segmentation fault, Michael Goffioul, 2008/01/07
- Re: octave-3.0.0+ segmentation fault, John W. Eaton, 2008/01/07
- Re: octave-3.0.0+ segmentation fault, Michael Goffioul, 2008/01/08