Re: What could cause this to fail under MallocScribble?
Re: What could cause this to fail under MallocScribble?
- Subject: Re: What could cause this to fail under MallocScribble?
- From: Jens Alfke <email@hidden>
- Date: Tue, 17 Jun 2008 12:38:01 -0700
On 17 Jun '08, at 11:14 AM, Fritz Anderson wrote:
Would this not happen if CoreAudio released a pointer (filling the
space with 0x55), and then did another malloc that reused the
pointer value (filling the space with 0xAA)?
That's the only thing I can think of. It's pretty common for an
allocator to reuse a recently-freed block of the same size in this way.
The new allocation need not be for the same purpose -- CA would, we
can presume, still have the stale value in its structures.
Oh, I see what you mean now — Yes, this could be a reference to a
freed block, and the only reason it's not showing up as 0x55 is that
something (not even necessarily CA) already allocated a new block of
the same size but hasn't put anything in it yet.
This would also explain why it didn't crash under LibGMalloc, which
was the next thing I tried.
Is there a way to get MallocScribble to overwrite only freed blocks,
not new blocks? (It's actually documented as doing so, but in reality
it does both.)
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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