Global variable in static library - double free or corruption error

[Vladimir Simonov]

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@gmail.com]
> Sent: Thursday, October 21, 2010 5:00 PM
> To: Alexey Skidanov
> Cc: gcc-help@gcc.gnu.org; skidanovalexey@yahoo.com
> 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@orbotech.com>  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
>>
>>
>
>