Re: "clear all" problem for classes defined in oct-files (Was: : bug) (Concerns: SWIG)

[David Bateman]

Xavier Delacour wrote:
> On Mon, May 26, 2008 at 11:16 AM, Michael Goffioul
> <address@hidden> wrote:
>> Note: this problem occurs in 3.0.1, but I could not check if it was present
>> in development code (it happens with SWIG-based code, but SWIG
>> support for octave is only available for 3.0.x branch, AFAIK).
> 
> I haven't been working on head, but I imagine it should work without
> any problems. (or at least I'm not currently aware of any). I'll give
> it a try when I get a chance.
> 
>> Basically, the problem is that "clear all" at octave prompt makes octave
>> crash when a SWIG-based package like "database" is loaded in memory,
>> more specifically the SQLite3 support. When loaded by octave, this
>> package installs various global variables, whose class is contained in the
>> oct-file sqlite3.oct. When calling "clear all", octave does the following:
>> 1) clear current symbol table (curr_sym_tab)
>> 2) clear functions of fbi_sym_tab
>> 3) clear global symbol table (global_sym_tab)
>>
>> Now the problem is that step 2) unmaps sqlite3.oct from process address
>> space. This invalidates the virtual table of sqlite3 objects contained in the
>> global symbol table. In step 3), clearing some of those objects results in
>> calling functions in the invalid virtual table and produces a segmentation
>> fault.
> 
> Won't any oct-file that installs a custom type have this problem if
> variables of that type are installed in the global symbol table? Off
> hand it seems like the correct solution is to swap steps 2 and 3. Or
> unload symbols etc in step 2, but only unload the shared libs in a new
> step 4.
> 
> I think this is only SWIG specific in that it installs a global
> variable at load time. Other packages that use custom types probably
> have the same problem, but you have to assign a global variable of the
> custom type to notice it.
> 
> You should also see a similar problem if you touch an oct-file that
> has installed a custom type (and an instance of it exists somewhere).
> Octave will try to reload the oct-file and make the type invalid.. and
> subsequently using the existing variable instance will cause a crash.
> 
> Xavier
> 

Yes the fixed type has the same issue. The solution used in the fixed
type is to "mlock" the constructor function in place when the package is
loaded so that "clear all" won't remove it.. fixed.oct currently uses

  // Lock constructor function in place, otherwise
  // "a=fixed(3,1); clear functions; a" generates a seg-fault!!
  // The below is the function "mlock", but in a way useable
  // for older versions of octave as well.
  fbi_sym_tab->lookup("fixed")->mark_as_static ();

for this purpose as mlock wasn't in some older 2.1.x versions of Octave.
However this is incompatible with 3.1.x, but mlock is incompatible
between the 3.0 and 3.1 versions as well, or at least

void mlock (const std::string&)

doesn't exist in 3.1.x yet.. I'd suggest using the above in any case,
and I believe we should readd the same function in 3.1.

Regards
David