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

[Soeren Sonnenburg]

On Tue, 2009-11-03 at 13:46 +0100, Jaroslav Hajek wrote:
> On Sat, Oct 24, 2009 at 3:05 AM, John W. Eaton <address@hidden> wrote:
> > On 21-Oct-2009, Soeren Sonnenburg wrote:
> >
> > | 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)):
> > |
> 
> > 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.
> >
> > 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.
> >
> > jwe
> 
> I inspected the code a bit, and the basic obstacle I see is the
> octave_shlib::close method, which runs a hook function for each
> registered function, and then forces dlclose() (or equivalent), even
> though there may still be references to the shlib object.
> 
> John, can you give me a clue why this is so?
> 
> I would imagine a more straightforward implementation of octave_shlib,
> being merely a reference-counted pointer to the library handle (or
> zero). Then, dlclose would simply be called when the reference count
> drops to zero - similar to array and all the other reference-counted
> stuff.
> 
> If this were true, classes defined via .oct files could simply attach
> a copy of the originating octave_shlib into the class, ensuring that
> the library won't be unloaded.
> This could result in multiple loads of the same file into memory, if
> it was modified after loading, but I didn't find any information that
> this is not possible.
> 
> Unless I'm missing something important, I'd volunteer for this job.
> Any comments?

From my outsiders viewpoint this sounds very reasonable (and is what I
do here too in shogun). But it is John here who would need to decide...

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