octave-maintainers
[Top][All Lists]
Advanced

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

Re: octave-3.0.0+ segmentation fault


From: John W. Eaton
Subject: Re: octave-3.0.0+ segmentation fault
Date: Sat, 05 Jan 2008 11:34:54 -0500

On  5-Jan-2008, Michael Goffioul wrote:

| On 1/5/08, Michael Goffioul <address@hidden> wrote:
| > The count is indeed 1, but rep is not undefined: it's an octave_dld_function
| > that corresponds to the autoloaded gnuplot_binary function from
| > __gnuplot_raw__.oct.
| 
| I tried to trace the problem a little bit more and found something weird.
| When gnuplot_binary is called a second time, as reported earlier in
| the backtrace, the code comes to ov.h:line 279, where "rep" is deleted:
| in this case, "rep" is an octave_dld_function representing the autoloaded
| function "gnuplot_binary" in __gnuplot_raw__.oct.
| 
| When switching to disassembly code, I noticed that the call "delete rep"
| goes through a frame corresponding to compiler autogenerated code,
| named "scalar deleting destructor". This little piece of code finally calls
| the octave_dld_function destructor with a code that is roughly described
| here: http://www.thescripts.com/forum/thread263644.html.
| 
| Now the problem is that this additional frame is located in
| __gnuplot_raw__.oct address space. So, when the octave_dld_function
| destructor unloads __gnuplot_raw__.oct from memory, this invalidates
| the frame and lead to a crash when unwinding the call stack.
| 
| I don't know if this can be considered as a compiler bug, nor why this
| frame is generated in the oct-file address space, but I really have a
| problem now, as octave is un-compilable for me...

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?

jwe


reply via email to

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