Re: gmalloc prevents a "Bus error"
Re: gmalloc prevents a "Bus error"
- Subject: Re: gmalloc prevents a "Bus error"
- From: Dmitry Markman <email@hidden>
- Date: Mon, 3 Oct 2005 22:59:16 -0400
take a look at
http://developer.apple.com/documentation/Darwin/Reference/ManPages/
man3/libgmalloc.3.html
(or from the terminal man 3 libgmalloc)
NAME
libgmalloc.dylib -- (Guard Malloc), an aggressive debugging malloc
library
DESCRIPTION
libgmalloc is a debugging malloc library that can track down
insidious
bugs in your code or library. If your application crashes when
using
libgmalloc, then you've found a bug.
libgmalloc uses the virtual memory system to identify such
bugs. Each
malloc allocation is placed on its own virtual memory page,
with the end
of the buffer at the end of the page's memory, and the next
page is kept
unallocated. As a result, accesses beyond the end of the
buffer cause a
bus error immediately. When memory is freed, libgmalloc
deallocates its
virtual memory, causing reads or writes to the freed buffer
cause a bus
error. Thus, nasty, hard-to-track-down bugs are immediately
obvious, and
you'll know exactly which code is causing the problem. This is
thread-threadsafe
safe and works for all uses of malloc(), NXZoneMalloc(),
NSZoneMalloc(),
and friends.
On Oct 3, 2005, at 9:22 PM, Corey O'Connor wrote:
On 10/3/05, Justin C. Walker <email@hidden> wrote:
On Oct 3, 2005, at 15:16 , Craig Maloney wrote:
I have a situation where running code from the command line give
"Bus error" (I'm probably going out-of-bounds on an array), running
in gdb (from xcode or manually from a shell) gets a
"EXC_BAD_ACCESS" signal. But then if I want to turn on aggressive
debugging and select the "Enable Guard Malloc" option from the
debug menu, the error completely goes away and the program
terminates normally.
Could someone explain to me in simple terms how turning on the most
aggressive memory checking could make the error disappear
altogether? Sorry if this is a bit elementary.
The simplest explanation, in the absence of real data, is the classic
"good garbage vs. bad garbage" scenario: presumably, you have
something like an uninitialized pointer, or (as you say) aggressive
use of indexing for array access :-}; when you change the address
space, which I believe you do when enabling the guard malloc stuff,
you just might get lucky in that what used to be "thin air" is now
valid real estate. Thus, what used to be a "bad access" is now just
access to junk.
I think Guard Malloc also adds a buffer space to each side of an
allocated block of memory. This buffer area is regularly checked to
see if it has been modified from it's initial values (Which is
probably a bunch of suitable magic values like: 0xDECAFBAD ;-) ). if
the buffer had been modified the malloc debug system should report
which memory segment the overflow occured in.
I have no idea when this check is performed though. Is it on
de-allocate? Every allocation? Just ocassianally? Or am I just
dreaming Guard Malloc works like MFCs malloc debugging feature? ;-)
In Craig's case, if Guard Malloc works like I say he should be able to
find out if he stepped beyond the range of his array easy enough.
--
-Corey O'Connor
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Dmitry Markman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden