Re: crashes when exiting octave and loading swig-wrapped code

[Soeren Sonnenburg]

On Fri, 2009-10-23 at 22:05 -0400, John W. Eaton wrote:
> On 21-Oct-2009, Soeren Sonnenburg wrote:

Dear John,

thanks for the answer!

> | I am seeing crashes when exiting octave when I use swig-wrapped code but
> | only when loading multiple modules (with potentially overlapping
> | variables/functions).
> | 
> | Well it seems to be some invalid delete/free occurring only when closing
> | octave (gdb & valgrind outputs follow):
> | 
> | (this happens when just *loading* multiple modules of the shogun toolbox
> | (http://www.shogun-toolbox.org)):
> |[...] 
> | initoctave:1> init_shogun
> | octave:2> 
> | ==22872== Invalid read of size 4
> | ==22872==    at 0xBC3EA96: std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
> | ==22872==    by 0xC37743C: exit (exit.c:75)
> | ==22872==    by 0x532CD5C: octave_main (octave.cc:890)
> | ==22872==    by 0xC35F5C5: (below main) (libc-start.c:222)
> | ==22872==  Address 0xfd364f0 is 16 bytes inside a block of size 36 free'd
> | ==22872==    at 0x4C21ACE: operator delete(void*) (vg_replace_malloc.c:346)
> | ==22872==    by 0xBC3EAA8: std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
> | ==22872==    by 0xC37743C: exit (exit.c:75)
> | ==22872==    by 0x532CD5C: octave_main (octave.cc:890)
> | ==22872==    by 0xC35F5C5: (below main) (libc-start.c:222)
> | ==22872== 
> | ==22872== Invalid free() / delete / delete[]
> | ==22872==    at 0x4C21ACE: operator delete(void*) (vg_replace_malloc.c:346)
> | ==22872==    by 0xBC3EAA8: std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
> | ==22872==    by 0xC37743C: exit (exit.c:75)
> | ==22872==    by 0x532CD5C: octave_main (octave.cc:890)
> | ==22872==    by 0xC35F5C5: (below main) (libc-start.c:222)
> | ==22872==  Address 0xfd364e0 is 0 bytes inside a block of size 36 free'd
> | ==22872==    at 0x4C21ACE: operator delete(void*) (vg_replace_malloc.c:346)
> | ==22872==    by 0xBC3EAA8: std::basic_string<char, std::char_traits<char>, 
> std::allocator<char> >::~basic_string() (in /usr/lib/libstdc++.so.6.0.13)
> | ==22872==    by 0xC37743C: exit (exit.c:75)
> | ==22872==    by 0x532CD5C: octave_main (octave.cc:890)
> | ==22872==    by 0xC35F5C5: (below main) (libc-start.c:222)
> [...]
> | ========snip==========
> | There have been a number of crashes (without good resolution) related
> | to the dynamic loading and clearing of .oct files in octave. These are
> | essentially bugs in octave itself, where if you load a module, create
> | some variables with it, clear the module, and then try to use the
> | variables, it will segfault etc. Those are likely related to your
> | problem (eg swig-octave registers a global variable that is not
> | cleared before the oct file itselt is cleared). Maybe a workaround is
> | to have a static destructor remove all swig-related global variables?
> | ========snip==========
> | 
> | Does anyone here have an idea what the culprit is?
> 
> Yes, it's a known problem that you can't load a .oct file that creates
> a variable (or is it just a user-defined class?) then clear the .oct
> file and expect to continue to use the variables that were created.
> I think you can avoid the problem by locking the .oct file that
> creates the object.

How could one lock the .oct file? It sounds to me that I *may* be lucky
when I reshuffle the order in which I load oct files...

> We've had some discussions about making Octave delay unloading the
> file until all objects created by it are deleted.  That might be
> better, but so far no one has done the work.

Sounds reasonable, does octave currently have any means to detect that a
variable or class is defined in a certain file?

Soeren
-- 
For the one fact about the future of which we can be certain is that it
will be utterly fantastic. -- Arthur C. Clarke, 1962

signature.asc
Description: This is a digitally signed message part