help-octave
[Top][All Lists]
Advanced

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

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


From: Jaroslav Hajek
Subject: Re: crashes when exiting octave and loading swig-wrapped code
Date: Tue, 3 Nov 2009 13:46:08 +0100

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?

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

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