crashes when exiting octave and loading swig-wrapped code

[Soeren Sonnenburg]

Dear all,

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)):

octave:1> init_shogun
octave:2> 

Program received signal SIGSEGV, Segmentation fault.
malloc_consolidate (av=0x7ffff08c1a00) at malloc.c:4891
4891    malloc.c: No such file or directory.
        in malloc.c
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7eab750 (LWP 22163)):
#0  malloc_consolidate (av=0x7ffff08c1a00) at malloc.c:4891
#1  0x00007ffff05e7e68 in _int_free (av=0x7ffff08c1a00, mem=0xc36ac0)
    at malloc.c:4782
#2  0x00007ffff05e81d6 in *__GI___libc_free (mem=0xc9f710) at
malloc.c:3625
#3  0x00007ffff14828b4 in ?? () from /usr/lib/libhdf5.so.6
#4  0x00007ffff1482924 in ?? () from /usr/lib/libhdf5.so.6
#5  0x00007ffff1485ba1 in H5FL_garbage_coll ()
from /usr/lib/libhdf5.so.6
#6  0x00007ffff1485fa8 in H5FL_term_interface ()
from /usr/lib/libhdf5.so.6
#7  0x00007ffff1392f85 in H5_term_library () from /usr/lib/libhdf5.so.6
#8  0x00007ffff05ab43d in *__GI_exit (status=0) at exit.c:75
#9  0x00007ffff73a3d5d in octave_main (argc=1, argv=0x7fffffffe428,
embedded=0)
    at octave.cc:890
#10 0x00007ffff05935c6 in __libc_start_main (main=0x400900 <main>,
argc=1, 
    ubp_av=0x7fffffffe428, init=0x400920 <__libc_csu_init>, 
    fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fffffffe418) at libc-start.c:222
#11 0x0000000000400839 in _start ()
(gdb) 


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)
==22872== 
==22872== 
==22872== HEAP SUMMARY:
==22872==     in use at exit: 37,844,498 bytes in 10,837 blocks
==22872==   total heap usage: 428,743 allocs, 417,946 frees, 67,396,361 bytes 
allocated
==22872== 
==22872== LEAK SUMMARY:
==22872==    definitely lost: 116,835 bytes in 167 blocks
==22872==    indirectly lost: 31,677 bytes in 196 blocks
==22872==      possibly lost: 1,871,115 bytes in 2,937 blocks
==22872==    still reachable: 35,824,871 bytes in 7,537 blocks
==22872==         suppressed: 0 bytes in 0 blocks
==22872== Rerun with --leak-check=full to see details of leaked memory
==22872== 
==22872== For counts of detected and suppressed errors, rerun with: -v


I've exchanged emails with the swig-octave maintainer (CC'ed) who
suggests:

========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?

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