On Fri, Jan 6, 2012 at 2:06 PM, John W. Eaton <address@hidden> wrote: > On 5-Jan-2012, Muhali wrote: > > | were you finally able to install the current octcdf, and actually verify the
> | segfaults? > > I am able to duplicate the problem, but I'm not sure that the problem > is with Octave. > > For example, the octcdf code has things like > > class octave_ncdim:public octave_base_value {
> public: > octave_ncdim(void):octave_base_value(), ncd(NULL) { } > > ... > > ~octave_ncdim() { > # ifdef OV_NETCDF_VERBOSE > octave_stdout << "destruct ncdim " << ncd << " count " << ncd->count << endl;
> # endif > ncd->count--; > > if (ncd->count == 0) { > # ifdef OV_NETCDF_VERBOSE > octave_stdout << "delete octave_ncdim: " << ncd << endl;
> # endif > delete ncd->ncfile; > delete ncd; > ncd = NULL; > } > } > > in each of the classes it derives from octave_base_value. It looks
> like trouble to me to have a constructor that unconditionally sets ncd > to NULL then unconditionally dereferences that value in the destructor > for the class.
I just was looking to the same issue now.
Indeed the destructor should check the pointer ncd and do nothing if it is NULL. But I'm have also the crash in octave_value_typeinfo.
> > Avoiding these problems by wrapping the body of the destructor with
> "if (ncd) { ... }" leads to another crash for me, this time inside the > destructor for the octave_value_typeinfo class. I'm not sure > precisely what's happening there, but I suspect a problem with
> calling a destructor for an octave_value object that is defined in a > shared library at a point when the shared library has already been > unloaded. Commenting out the call to singleton_cleanup_list::cleanup
> in do_octave_atexit in toplev.cc avoids the problem. I think the > proper fix would be to remove the dynamically loaded data type from > the octave_value_typeinfo list when the shared library is closed. I
> haven't checked to see whether that is already something that is easy > to do. > > I'm leaning toward leaving the call to singleton_cleanup_list::cleanup > commented out for the 3.6.0 release. We weren't doing this cleanup in
> previous versions and it seems a bit risky since we don't seem to have > all the cleanup sequence issues worked out yet. > > Comments? > > jwe
In case it is helpful, the crash in octave_value_typeinfo can be reproduced also with the make_int example from octave (see below).
I am using octave 3.5.91. I also noticed that if I do not call "<myobjects>::register_type ()" in octcdf, I do not get the crash in octave_value_typeinfo when octave closes. Is register_type() really needed?
Thanks and regards, Alex
$ gdb octave GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/abarth/opt/octave-3.5.91/bin/octave...done.
(gdb) run -f --eval 'myint = make_int(10)' Starting program: /home/abarth/opt/octave-3.5.91/bin/octave -f --eval 'myint = make_int(10)' [Thread debugging using libthread_db enabled] GNU Octave, version 3.5.91
Copyright (C) 2011 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'.
Octave was configured for "x86_64-unknown-linux-gnu".
For information about changes from previous versions, type `news'.
installing integer type at type-id = 54 myint =
10
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff75bc42b in octave_value_typeinfo::~octave_value_typeinfo() ()
from /home/abarth/opt/octave-3.5.91/lib/octave/3.5.91/liboctinterp.so.0 (gdb) where #0 0x00007ffff75bc42b in octave_value_typeinfo::~octave_value_typeinfo() () from /home/abarth/opt/octave-3.5.91/lib/octave/3.5.91/liboctinterp.so.0
#1 0x00007ffff75bc526 in octave_value_typeinfo::cleanup_instance() () from /home/abarth/opt/octave-3.5.91/lib/octave/3.5.91/liboctinterp.so.0 #2 0x00007ffff63003eb in ~singleton_cleanup_list (this=0x7fffecfe31d0, __in_chrg=<value optimized out>)
at singleton-cleanup.cc:39 #3 0x00007ffff74a3948 in singleton_cleanup_list::cleanup () at ../liboctave/singleton-cleanup.h:26 #4 do_octave_atexit () at toplev.cc:1085 #5 0x00007ffff74a50c8 in clean_up_and_exit (retval=-318885424) at toplev.cc:670
#6 0x00007ffff744d8fa in octave_main (argc=4, argv=0x7fffffffe168, embedded=<value optimized out>) at octave.cc:907 #7 0x00007ffff5543c4d in __libc_start_main () from /lib/libc.so.6 #8 0x00000000004005e9 in _start ()
(gdb)