Hi Alexey,
I saw the same thing in Crypto++ when distributions began
porting/packaging as shared object [1, 2]. The mailing list was
getting 'double free' reports under obscure circumstances [3]. [2] was
a test case to reproduce and looks exactly like your analysis :).
Anyway, the fix is to hide the the global TestClass:
OLD:
TestClass test_var;
NEW:
TestClass& GetTestClass()
{
static TestClass test_var;
return test_var;
}
I just opened a feature request for a -Wglobal-variable for this sort
of thing: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097.
You might chime in on the issue since the GCC team is contemplating
whether the feature is even worth while. I claim it is because this
behavior has jumped up a bit a few people in the ass. I was thinking
that -Wglobal-variable should be a part of -Wextra, and possibly
-Wall.
Jeff
[1] http://www.cryptopp.com/wiki/Linux#Shared_Objects_and_Globals
[2] RTLD_GLOBAL and libcryptopp.so crash,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
[3] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48
On Thu, Oct 21, 2010 at 7:53 AM, Alexey Skidanov
<Alexey.Skidanov@xxxxxxxxxxxx> wrote:
> Hello,
> We use the gcc 4.1.1 in our project. After some code refactoring
> (creating new shared library) the application crashes at exit with
> following error:
>
> *** glibc detected *** : double free or corruption (fasttop) ***
>
> In order to simulate our application, I created the test one, with two
> shared libraries and one static library. The code is below:
>
> [SNIP]
>
> Static library defines some global variable (test_var), that during
> library linking "injected" into the dynamic library bss segment.
> Actually, static.o object file is linked with dynamic1.o and with
> dynamic2.o files.
> Please, pay attention that constructor and destructor of the SAME
> INSTANCE (at address 0x60ca9c) of global variable were called twice - at
> each dynamic library start up. Generally, it seems that this is partial
> solution of double definition problem during main application linking:
> Dynamic linker somehow merges two definition of the same global variable
> - but each shared library start up code contains calls of this variable
> constructor and destructor.
>
> I would expect that TWO different instances of the global variable would
> be created in TWO different shared libraries - maybe with name mangling.
>
>
> Is this a linker/loader bug? Can we cause (by linker/loader options)
> linker/loader more consistent behavior?
>
> Thanks,
> Alexey
>
>
