OK, I found the culprit. As suspected, it has nothing to do with sheets.
I'm using a sorting function with NSMutableArray:
static int cmpColorStops (DKColorStop* lh, DKColorStop* rh, void
*context)
{
#pragma unused(context)
float lp = [lh position];
float rp = [rh position];
if (lp < rp)
return NSOrderedAscending;
else if (lp > rp)
return NSOrderedDescending;
else
return NSOrderedSame;
}
- (void) sortColorStops
{
[m_colorStops sortUsingFunction:cmpColorStops context:NULL];
}
In my original code, the sort function was declared:
static int cmpColorStops (id lh, id rh, void *context);
Which compiled just fine. Problem is that rp = [rh position]; was
returning some utterly bogus value, because the assumption was an
int(?) was being returned from the anonymous object type, not a float.
Specifically typing the parameters to the sort function removes this
ambiguity. As it turns out, the bogus values did sort correctly,
because their relative values were in the right order, which is why
I've never spotted this before. What I'm still not clear about is how
this can cause memory corruption, because a float and an int are the
same size. I'm also not sure why it was OK on Tiger (though possibly
just due to chance layout differences in memory).
Further thought: could it be that in Tiger, no Cocoa objects declare a
method called -position, so it correctly picked up my private object's
method signature. In Leopard, both CALayer and NSPositionalSpecifier
declare a -position method, so the compiler is assuming one of those
for the anonymous objects. CALayer's version returns a CGPoint, which
being larger than a float could explain the memory corruption?
I've actually run into almost the same bug before and it was equally
hard to track down. It would be useful if there was a compiler warning
for an implicit cast or mismatch of return type in cases like this,
because otherwise they are devilishly hard to spot. If there is such a
warning, please tell me, so I can spare myself future hunts of this
kind (this one has taken a solid 11 hours to find and fix, primarily
because cause and effect were completely unrelated!)
Thanks to everyone who pitched in - very grateful.
cheers, Graham
On 5 Jun 2008, at 11:08 pm, Andy Lee wrote:
If there were a Dr. House for debugging, this is the kind of
diagnostic challenge he'd like.
Stab in the dark: you mentioned that you're on 10.5.3. Do you have
a 10.5.2 machine you can use to see if the hang still occurs? Maybe
it's not a Tiger/Leopard thing but a 10.5.2/10.5.3 thing.
--Andy
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
