Re: memory allocation / linking in libstdc++ from gcc 3.2.2

[Carlo Wood <carlo at alinoe dot com>]

On Sat, Mar 29, 2003 at 11:39:08PM +0100, Ivan Popov wrote:
> Hello,
> 
> I am not quite sure if it is the right place to ask, as the problem may be
> outside libstdc++, but I can't figure out whether it is the case.
> 
> I have a homegrown installation with different versions of glibc, binutils
> and gcc located at non-standard places. To be sure they do not pollute
> each other, I keep the "standard" places like /usr/include and /usr/lib
> as empty as possible. I am pretty sure the setup is healthy and I have run
> it for a while. Most of the time I am running programs with explicit
> dynamic loader and corresponding --library-path, but for testing I am
> hardwiring the implicit dynamic loader as well, via specs, and setting
> LD_LIBRARY_PATH properly.
> 
> Now the problem I have identified:
> 
> "Groff" that is written mostly in c++ works fine with libstdc++ from 3.2
> or when statically linked with libstdc++ from 3.2.2
> but gets corrupted memory allocation when dynamically linked to 3.2.2.
> 
> Google was unable to find references to this problem.
> A possible explanation is that nobody has compiled and run groff with
> glibc 2.3.2, gcc 3.2.2, binutils 2.13.2.1 for i486 on an AMD Athlon?..
> :)
> 
> (of course it is compiled against right headers and linked against right
> libs, as much as I can check, up to running strace at both compile and
> run time)
> 
> I have found that groff redefines the "new" operator, in fact with
> code very similar to the stdlibc++ one. But it is apparently getting
> linked at runtime to a different malloc (glibc's) than stdlibc++ one.

Perhaps... and I am just guessing because of your phrase " apparently getting
linked at runtime to a different malloc", this is related to versioning.

If certain symbols are versioned then these versions need to be stored
in the application as well, so that later the correct version will be
used to link with.

What can happen is that you link a shared module (of groff?) with another
shared library with versioned symbols, but without specifying the -llibrary
during linking.  The result will be that the resulting shared library will
not have the versions of the symbols of that shared library, and therefore
possibly link at runtime with the wrong function.

Thus:

application needs lib1 and libmalloc, it is linked with -lmallloc and
adds the version in libmalloc to link with malloc(GLIBC_2_2).

lib1 needs lib2 but does NOT link using -lmalloc, and therefore ends
up with symbols 'malloc' (without version).

Now, the application 'loads' lib1, and uses both 'malloc(GLIBC_2_2)'
and 'malloc' plain - the latter can be a different version however.

Hope this helps.

-- 
Carlo Wood <carlo at alinoe dot com>