Re: libgmalloc problem
Re: libgmalloc problem
- Subject: Re: libgmalloc problem
- From: Eric Albert <email@hidden>
- Date: Thu, 01 Nov 2007 22:02:38 -0700
On Nov 1, 2007, at 1:48 PM, Terry Lambert wrote:
On Nov 1, 2007, at 5:16 AM, Martin Mitas wrote:
Hi all.
Hopefully this is the right list to report this problem.
To debug our SW, we try to use libgmalloc, as described here:
http://developer.apple.com/technotes/tn2004/tn2124.html
However we encountered troubles with libgmalloc. The following
simple program is good enough to demonstrate it.
[ ... ]
$ gcc -O2 -fomit-frame-pointer problem.c
$ DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib ./a.out foo bar
Allocations will be placed on word (4 byte) boundaries.
- Small buffer overruns may not be noticed.
- Applications using AltiVec instructions may fail.
GuardMalloc-11
Segmentation fault (core dumped)
GNU Malloc's alignment boundaries are insufficiently stringent for
floating pint register spills, which happen when autovectorization
happens (which is enable in the compiler by default), or when
explicitly using floating point.
This isn't GNU malloc; it's Guard Malloc. But if the alignment issue
mentioned above is the issue here (which is quite rare with gmalloc
in my experience, since data types requiring 16-byte alignment are
usually allocated in multiples-of-16-bytes chunks, which results in
them being properly aligned), you can work around it by setting the
MALLOC_VECTOR_SIZE environment variable to 1. See the libgmalloc man
page for details.
GCC on Mac OS X doesn't autovectorize by default, by the way.
Terry's probably thinking of how we use the XMM registers for
floating point operations by default, which means that we use the SSE
instructions. But we use scalar versions of those instructions, and
the compiler doesn't automatically vectorize code patterns unless you
explicitly tell it to.
That said, this crash doesn't have anything to do with floating
point, and it doesn't appear to have anything to do with
misalignment. It doesn't crash on Leopard, but on 10.4.10, it
crashes while dereferencing $eax, when $eax is "argv". Debugging it
a bit and staring at the gmalloc source code for 10.4.10, I'm
guessing that gcc's __builtin_frame_address() doesn't work very well
when building with -fomit-frame-pointer. You can avoid this code by
setting the undocumented MALLOC_NO_BACKTRACE environment variable to
1. When I do that, your code runs to completion.
Hope this helps,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden