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: Fritz Anderson <email@hidden>
- Date: Tue, 17 Jun 2008 13:14:30 -0500
On 17 Jun 2008, at 12:05 PM, Jens Alfke wrote:
I've run into* what appears to be a bug in CoreAudio, which only
manifests when MallocScribble is turned on. The symptom is that a
property-accessor function, which is supposed to copy data into a
buffer, instead copies garbage consisting entirely of 0xAA bytes.
Even though this probably isn't my bug, I'm still trying to think of
what could cause this to happen, and drawing a blank.
I could easily understand this if the garbage consisted of 0x55,
since that's what MallocScribble writes into freed blocks. That
would simply indicate that CoreAudio had just freed the block
containing the property data, before copying it into my buffer.
But 0xAA is the pattern written into _new_, uninitialized malloc
blocks. How could CA be copying from an uninitialized block, but in
the absence of MallocScribble the block just happens to contain the
proper data? I can't figure it out. I'm almost wondering if it's a
bug in the implementation of MallocScribble, somehow.
...
* http://lists.apple.com/archives/CoreAudio-API/2008/Jun/msg00133.html
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)?
The new allocation need not be for the same purpose -- CA would, we
can presume, still have the stale value in its structures.
— F
_______________________________________________
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