[Octave-bug-tracker] [bug #41699] imformats causes a segmentation fault on Windows when Octave exits

[Rik]

Follow-up Comment #89, bug #41699 (project octave):

I used gdb in Windows to check various values at the time of the segfault. 
First, I get the same backtrace as John D. in comment #88.  The code in
question at Array.h:222 is


virtual ~Array (void)
{
  if (--rep->count == 0)
    delete rep;
}


The rep pointer is not null at this point, but there is something wrong
because gdb will not let me read that memory location.  This may be related to
the read-only property for the ICO and CUR formats.  This may also be the
cause of the segfault.  The rep pointer is somehow set up in a region of
memory that is read only.

>From the Wikipedia page on virtual functions


Virtual destructors

Object-oriented languages typically manage memory allocation and de-allocation
automatically when objects are created and destroyed. However, some
object-oriented languages allow a custom destructor method to be implemented,
if desired. If the language in question uses automatic memory management, the
custom destructor (generally called a finalizer in this context) that is
called is certain to be the appropriate one for the object in question. For
example, if an object of type Wolf that inherits Animal is created, and both
have custom destructors, the one called will be the one declared in Wolf.

In manual memory management contexts, the situation can be more complex,
particularly as relates to static dispatch. If an object of type Wolf is
created but pointed to by an Animal pointer, and it is this Animal pointer
type that is deleted, the destructor called may actually be the one defined
for Animal and not the one for Wolf, unless the destructor is virtual. This is
particularly the case with C++, where the behavior is a common source of
programming errors.


This looks scary, but it seems we are following the correct pattern and made
the base object destructor a virtual function so that it can be overriden.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?41699>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/