[Bug c++/44059] New: Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

With g++ 4.5.0 static initializers can be executed more than once.
Here's how. Let a.cc contain the following code:

#include 

struct A {
  A() {
static int x = printf("x initialized at @%p\n", &x);
  }
};

extern "C" void inita();

void inita()
{
  A x;
  A y;
}

And let b.cc be the copy of a.cc where 'inita' has been renamed
to 'initb'. Then make a shared library a.so from a.cc and b.so from
b.cc. Finally, make a program that dynamically loads a.so and b.so
and calls inita and initb functions.

Since 'x' ends up as a unique global symbol, there will be only one
object in the process, but the initialization code will be run twice
(the address printed will be the same).


-- 
   Summary: Static initializers executed more than once when using
unique global symbols
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan dot stankovic at avl dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

--- Comment #1 from ivan dot stankovic at avl dot com  2010-05-10 13:40 
---
Created an attachment (id=20619)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20619&action=view)
The test case

Just unpack and run 'make; make run'. The output
should be something like:

x initialized at @0x40021a28
x initialized at @0x40021a28

(note that the addresses are identical).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

--- Comment #5 from ivan dot stankovic at avl dot com  2010-05-10 14:14 
---
Indeed, using RTLD_GLOBAL works around the problem. However, I don't think
one should just resort to using this flag with dlopen everywhere. The problem
was originally found with Python modules written in C, and while one can
change the dlopen flags used for Python imports, I'm not sure that that won't
break something else.

As Jakub has pointed out, the guard needs to be unique as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059