memory allocation / linking in libstdc++ from gcc 3.2.2

[Ivan Popov <pin at math dot chalmers dot se>]

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.
Disabling this code in groff-1.18.1/src/libs/libgroff/new.cc
[Debian version, follows below]
makes groff behave nicely.
--------------  [COOKIE_BUG not defined]
 [skipped....]
#include "lib.h"

#include <stddef.h>
#include <stdlib.h>

#include "posix.h"
#include "nonposix.h"
 [skipped....]

#if 0 /* pin -- my correction */

void *operator new(size_t size)
{
  // Avoid relying on the behaviour of malloc(0).
  if (size == 0)
    size++;
#ifdef COOKIE_BUG
  char *p = (char *)malloc(unsigned(size + 8));
#else /* not COOKIE_BUG */
  char *p = (char *)malloc(unsigned(size));
#endif /* not COOKIE_BUG */
 [skipped check for p==0 ....]
  return p;
}
 [skipped....]
--------------

I want either to be convinced about what is my fault,
or to be told that it is groff doing wrong (it does not redefine delete)
or to help fixing the library/linker problem if it exists.

My speculations are as follows:

3.2 libstdc++ does not contain its own malloc, so the whole works fine.
With 3.2.2 static linking happens most probably in different order
than the dynamic one and hence gives a consistent result.

I can think that it is a dynamic loader bug (it happens independently of
using implicit or explicit dynamic loader, if it matters).

If it is a groff mistake, why would it be hidden by statical linking?

Any suggestions are appreciated.

Best regards,
--
Ivan