Serious C++ linking error

Serious C++ linking error

[Jason Gunthorpe]

Hi,

Some number of months ago someone reported a problem with C++ strings
leaking memory when some parts of a program are compiled with -fPIC. Since
this has been bothering me for months and months I sat down and have
tracked this down to the real cause. I hope someone can fix it!

It appears that my eg++ is causing .o files linked with -fPIC to
dynamically link to template symbols located in libstdc++2.9, while my
other .o files link to a local copy of those template symbols. One of
these symbols is the free_list in the __default_alloc_template - the
default allocator for the string class.

Since there are two seperate free_list symbols what happens is that the
shared library allocates a new object, then gives that to the caller who
then releases it onto it's copy of the free_list, this goes around and
around until there are thousands of objects on the second free list - it
shows up as a memory leak as it never gets reused or freed.

I am also concerned that there is no mechanism for releasing allocated
memory in the __default_allocator class, but that is a side issue.

The test code is pretty simple (included below), compile with:

g++ -fPIC -c leaklib.cc
g++ -o leaktest leaktest.cc leaklib.o 

And running gives this:

Deallocate is: 0x804a420
Deallocate2 is: 0x40031790

And ldd shows that 0x40031790 is in libstdc++
ldd ./leaktest
        libstdc++-libc6.0-1.so.2 => /usr/lib/libstdc++-libc6.0-1.so.2 (0x4000f000)
        libm.so.6 => /lib/libm.so.6 (0x40053000)
        libc.so.6 => /lib/libc.so.6 (0x4006e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

My platform is Debian 2.1 i386 linux glibc 2.0:
gcc version egcs-2.91.60 Debian 2.1 (egcs-1.1.1 release)

And I have verified the results on Debian 'potato' i386 linux glibc2.1
with,
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)

Both of the above work fine if the -fPIC is omitted.

And also Debian 'potato' sparc linux glibc2.1 with,
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)
However, the sparc only shows the different symbol addresses, not the
memory leak side-effect, perhaps the free_list symbol is not duplicated...

I was -NOT- able to reproduce this on Debian 'potato' alpha linux glibc2.1 
with,
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)

Thanks,
Jason

---- leaktest.cc ----
#include <malloc.h>
#include <string>

string get_string ();

void leak ()
{
   string tmp = get_string();
}

int main ()
{
   cout << "Deallocate is: " <<
      (void *)&__default_alloc_template<1, 0>::deallocate << endl;

   while (true)
   {
      leak();
//      malloc_stats();
   }

   return 0;
}
------------
---- leaklib.cc ----
#include <alloc.h>
#include <iostream>

#include <string>

string get_string ()
{
   cout << "Deallocate2 is: " <<
      (void *)&__default_alloc_template<1, 0>::deallocate << endl;
   return "blah";
}

Re: Serious C++ linking error

[Jason Gunthorpe]

On Sun, 4 Jul 1999, Martin v. Loewis wrote:

> > It appears that my eg++ is causing .o files linked with -fPIC to
> > dynamically link to template symbols located in libstdc++2.9, while my
> > other .o files link to a local copy of those template symbols. One of
> > these symbols is the free_list in the __default_alloc_template - the
> > default allocator for the string class.
> 
> This should work, as the dynamic linker should resolve the duplicate
> symbols as one during runtime. Without further analysis, I suggest to
> update binutils.

I am using binutils 2.9.1.0.24:

pandora{jgg}~#ld -v
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)

I'd be alarmed if this was not a sufficiently new version... Can I provide
anymore information?

Jason

Re: Serious C++ linking error

[Martin v. Loewis]

> I'd be alarmed if this was not a sufficiently new version... Can I
> provide anymore information?

I'm not an expert at these things, but how about output of objdump
--syms of the relevant objects?

Regards,
Martin

Re: Serious C++ linking error

[Martin v. Loewis]

> It appears that my eg++ is causing .o files linked with -fPIC to
> dynamically link to template symbols located in libstdc++2.9, while my
> other .o files link to a local copy of those template symbols. One of
> these symbols is the free_list in the __default_alloc_template - the
> default allocator for the string class.

This should work, as the dynamic linker should resolve the duplicate
symbols as one during runtime. Without further analysis, I suggest to
update binutils.

Regards,
Martin

Re: Serious C++ linking error

[H.J. Lu]

I am enclosing a simplified testcase for the bug. It is a very
complicated bug due to the weak symbol handling in glibc and gld. It
doesn't happen on Solaris where weak symbols in DSO are treated as
strong and the dynamic linker treats all weak symbols as strong.

I don't know if there is a reasonable fix from glibc or gld. I tend
to believe the bug is in g++. Basically under glibc, for the same
symbol, g++ has to make it either weak or strong in all cases,
compiler-generated or not. Otherwise, bad things can happen.



-- 
H.J. Lu (hjl@gnu.org)
--
begin 644 shared.tar.gz
M'XL(`"CL?S<``^U876_:,!3E%?^*.\HFJ$@:FWQ(9-U6T76:MJE5^]"'=9-"
MXH"WX%0AB$[3_OOLA*1`H;330A_J\Y`0V]?WVK['/G@R\A(:D(-:A0#3<"P+
M:@#8L0SY!MPEV7L.`\!VNHYCVT;7$;6&Z9`:6%4&56`Z2;T$H#;Z$=W;3C0+
MPUT$M%M,YNL?QK'N5^0#&X9MFIO7'SMFL?[$$HD"&%L&KH%143Q+>.;KO\>X
M'TT#"J\G:<!B??0&(<93"*@71;'OI10.P7#SPGTDT@1:;?0;`5PGHBB$5N/X
MXK0#HJ('QLW+FRO>Z,"K6_.V*]HF-)TF?+'817_04X]=X9;_7[R?-&01K<+'
M%OYCT^@6_.\2T0`P(=A1_-\%^B>?CSY<'&JGH`T1.CL_%1^2S%@^",RRG_))
M$!+<[4&SE35JHWH8)Q`"XV61"T$,U!_%T#B?<L[X4#1OA@T7]`/Q=N$*U0%8
M"%]%\5MX(386^.9".J(\-SOQ1`8&+H1,=L4IDOL-[D'$!O)\FL0P]AC7?1AX
M"=9C5&^V^OTV:#$TWXDH\K&TH?D=M,NHHR777CKJZ%DO9'TOY!&]Y$Y[TDSW
MEZTT'[3P[&-_R3RS()LMEMO.-@QUMC+6)/C%O3'S[\2K'5^^/_IT-^S9AM'/
M5H;_^(X?.R'SGG++!TY,:5/&WX-,JY16^0Y66*]9!3^B'N^A>C(6U66RPKZ<
MBWTQ`4]-P2=%L?_G25&-CVWZSR2XU'\V-J7^L[M*_^T$>RP,:`@9Q_:N$V\X
M]F!&O9\+`G"M'MRCT62U1I;R@(5SL2C9+<2B.__*I6.N))%,MUQ((A$!&"@[
M%UH+`E$>#WD';223Q!O$29IUD+M>$*#TAOJ=;%N[1X(6[J$,JPBVE*?&,Q2E
M!?_U83!@G*55^-C&?\"VX'_7PL0B#L92_PD%J/B_"PP2279!#I1,^7-+?H62
M_YD2J\C'-OX3Q[Z]_S&S^Q_3-A7_=X%U]S\/T03_*@KD?Z+5"Z3\_!85Z@9)
;04%!04%!04%!04%!04%!X;_C+^),&@L`*```
`
end
>From oliva@dcc.unicamp.br Sun Jul 04 21:13:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Ovidiu Toader <ovi@physics.utoronto.ca>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: namespace triggers an ICE in 19990621
Date: Sun, 04 Jul 1999 21:13:00 -0000
Message-id: <or3dz3ag4t.fsf@cupuacu.lsd.dcc.unicamp.br>
References: <377E957A.18FBB29@physics.utoronto.ca>
X-SW-Source: 1999-07/msg00151.html
Content-length: 592

On Jul  3, 1999, Ovidiu Toader <ovi@physics.utoronto.ca> wrote:

> If class A is not defined inside namespace NL then no ICE is reported.

> namespace NL { template <typename T> class A { template <typename
> T_> friend class A; }; }

Thanks, I'm adding a simplified version of your testcase in the
testsuite.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists