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

[Xavier Delacour]

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