This is the mail archive of the
mailing list for the glibc project.
Re: malloc patch for 2.2.4
- To: chris at ludwig-alpha dot unil dot ch
- Subject: Re: malloc patch for 2.2.4
- From: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Date: Wed, 29 Aug 2001 11:56:18 +0200 (MDT)
- CC: libc-alpha at sources dot redhat dot com
- References: <200108290928.LAA16497@ludwig-alpha.unil.ch>
> I have a problem here that might be related to the malloc problem you are
> trying to fix.
> I have compiled this package on several platforms (Solaris, HPUX, and Linux).
> On HPUX and Solaris, it runs fine in single- and multi-threaded mode.
> With current glibc releases, it runs fine in single-threaded mode, but gets a
> SegV in multi-threaded mode (the thread mode is selected by a run-time
> switch). A typical back-trace looks like this:
Note that the problem I am still chasing only occurs on ia32 SMP,
i.e. with at least 2 CPUs. No problem with multiple threads on a
> I have tried to compile with -fno-strict-aliasing. I have tried to apply your
> malloc volatile patch. Still, I get the same behaviour.
Not too surprising, as I've found it doesn't change the generated code
at all. Sorry.
Like Jakub said, try MALLOC_CHECK_=1 first, then Electric Fence, if
you can afford the exploding memory usage of the latter. If that
doesn't show anything and you suspect similarity to 'my' problem
(i.e. you have 2 CPUs), try a glibc compiled with debug info. With
'my' problem, I am usually seeing stack/register corruption, in
particular last night I saw that the %ebx register was mysteriously
corrupted. Any help with the 'fork-malloc' test is still greatly