Re: Crash/Freeze in Xcode debugger w/infinite loop
Re: Crash/Freeze in Xcode debugger w/infinite loop
- Subject: Re: Crash/Freeze in Xcode debugger w/infinite loop
- From: Steve Sisak <email@hidden>
- Date: Sun, 23 Apr 2006 09:04:03 -0400
At 10:53 AM +0000 4/23/06, Trygve Inda wrote:
OSStatus DB_CallbackEndianFlip (OSType dataDomain, OSType dataType, short
id, void *dataPtr, UInt32 dataSize, Boolean isNative, void *refcon)
{
UInt32 count = dataSize >> 2; // number of 4-byte elements
while (--count >= 0) ((long *)dataPtr)[count] = isNative ?
EndianS32_NtoB (((long *)dataPtr)[count]) :
EndianS32_BtoN (((long *)dataPtr)[count]);
return (noErr);
}
Note the bug in count (declared as UInt32 instead of SInt32).
Of course a UInt32 will never be negative so this is an infinite loop. I got
the spinning pizza of doom and then it seemed to overwrite the video buffer
as my screen filled with blue from the bottom up.
Has anyone seen this happen? If it is not already filed, I will file a bug.
It should be able to break out of such conditions w/o having to do a hard
power down.
Well, your code is byte swapping all of the memory in your address
space in reverse order and is going to trash memory until it hits an
unmapped page.
As far as not being able to break, it looks like this code is being
"excessively clever" and trying to do the entire loop in one
statement leaving nowhere for Xcode to set a breakpoint inside the
loop.
Not only does this lead to obfuscated code, it leads to slow code --
note that the test on isNative in inside the loop.
Try rewriting your code to be clear and free of side-effects so the
optimizer can do its job:
{
UInt32 count = dataSize >> 2; // number of 4-byte elements
UInt32 index = 0;
long data = (long*) dataPtr;
if (isNative)
{
for (index = 0; index < count; index++)
{
EndianS32_NtoB(&data[index];);
}
}
else
{
for (index = 0; index < count; index++)
{
EndianS32_BtoN(&data[index];);
}
}
return (noErr);
}
(If you really care about code size, you can recognize that
EndianS32_NtoB and EndianS32_BtoN do the same thing and the test
against isNative is unnecessary)
Not only does this make your code more readable and give you a place
to set a breakpoint, it also makes life easier for the optimizer to
figure out what you meant and generate correct, fast code.
In general, it's better to declare separate variables for each
purpose and let the compiler handle register allocation. Also, assign
proper types to void* parameters on entry, rather than casting in
line -- if you never use the parameter after the assignment to the
typed pointer, this should be free.
You're not saving much, if anything, by eliminating 'index' and
looping backward because most processors/cache controllers optimize
sequential memory access.
Also, you'd better believe that optimizer has a special case for "for
(i=0; i<limit; i++) where i is used as an index to an array -- for
instance, it's free to generate an address offset and increment it by
4 -- look at the generated code if you care about optimization.
In any case, see if this helps.
-Steve
_______________________________________________
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