[Octave-bug-tracker] [bug #47372] Memory leaks and segmentation faults in Octave

[John W. Eaton]

Follow-up Comment #69, bug #47372 (project octave):

Visibility attributes will help, but that's not the real problem here.

The problem is whether a static symbol is uniquely defined.

After doing some more testing, I think the following are true:

If you have something like the following function defined in a header file
that is included in multiple source files, then *on Windows systems* you'll
see multiple definitions of the static variable, one per source file.  And
then initialization of that (unshared) "static" variable happen mulitple
times.


class dim_vector {
  ...
  static octave_idx_type *nil_rep (void)
  {
    static dim_vector zv (0, 0);
    return zv.rep;
  }
  ...
};


If the definition is moved to a source file, leaving only the declaration in
the header file, then you'll get only one copy and a single initialization.

This is different from what happens on (modern?, some?) Unixy systems where
only one copy of the static variable is created (or at least, used).

You can see the difference with nm.  On Windows systems, each instance of the
static variable has storage class "D" (The symbol is in the initialized data
section.) and on my GNU system I see "u" (The symbol is a unique global
symbol.  This is a GNU extension to the standard set of ELF symbol bindings. 
For such a symbol the dynamic linker will make sure that in the entire process
there is just one symbol with this name and type in use.)

Given that this behavior might be GNU-specific, maybe it would be best to move
these function definitions to 

Another solution appears to be defining static class data members instead of
function-scope static variables.  The advantage of doing that is it allows the
nil_rep function to be inlined.  The disadvantage is that it moves the static
variable outside of the function, and (with current C++ rules) it must be
initialized separately.  It seems simpler to just move these functions to
source files.

There is an additional problem with implicit instantiation of templates
leading to multiple definitions of function-scope static variables.

I don't see how visibility attributes can help with these problems.  For
MinGW, we are not using visibility attributes (everything is exported) and
there were no warnings about the static variables being defined multiple
times.

    _______________________________________________________

Reply to this item at:

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

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