Hi all,
Have you tried to add -fvisibility=hidden to
"g++ -g -c static.cpp -o static.o" ?
I guess it should fix the problem. Sorry, I have no gcc 4.1.1
to check. As I remember gcc 4.1.x had -fvisibility=default by
default. Newer gcc has -fvisibility=hidden.
Really it is very good thing to have -fvisibility=hidden
as default (specified explicitly in command line),
especially for shared libraries.
Best regards
Vladimir Simonov
On 10/21/2010 07:34 PM, Alexey Skidanov wrote:
Hi Jeffrey,
Thanks for your response. You are absolutely right regarding to
-Wglobal-variable. I would prefer to get some kind of error (linking
error?) about two global variables with the same name instead of dynamic
loader/linker decision to "merge" them.
Thanks,
Alexey
-----Original Message-----
From: Jeffrey Walton [mailto:noloader@xxxxxxxxx]
Sent: Thursday, October 21, 2010 5:00 PM
To: Alexey Skidanov
Cc: gcc-help@xxxxxxxxxxx; skidanovalexey@xxxxxxxxx
Subject: Re: Global variable in static library - double free or
corruption error
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/7eae0
09a4e02e726
[3] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc
22e8c6e2f48
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
