octave-maintainers
[Top][All Lists]
Advanced

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

singleton cleanup issues (was: Re: Fwd: octave segfaults during exit)


From: John W. Eaton
Subject: singleton cleanup issues (was: Re: Fwd: octave segfaults during exit)
Date: Fri, 6 Jan 2012 08:06:31 -0500

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.

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


reply via email to

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