I say crash, it doesn't actually say what caused gdb to trigger, but
it's the same stack trace every time. If I run under the debugger
initially, it crashes as usual, but things enter a very strange state
where the entire machine becomes very unresponsive and slow, the fans
ramp up to maximum - though Activity Monitor only shows my app using
about 3% CPU. If I don't launch it with gdb, gdb cuts in when this
occurs, shows this stack trace with no other explanation, but I don't
experience the machine slowdown. More like a hang than a crash then,
but it's not an infinite loop as gdb is stopped, not waiting for me to
pause it.
I'm not sure what's going on. I can work around the problem by not
drawing shadows when I hit-test and that "fixes" it (and I can live
without shadows not being hit-testable), but if there is a bug in the
bowels of Quartz I expect someone might like to know about it.
Graham
On 22 Jul 2008, at 12:33 pm, Ken Thomases wrote:
On Jul 21, 2008, at 9:01 PM, Graham Cox wrote:
Stack trace:
#0 0x940101fc in sseCGSFill8by1
#1 0x93d89107 in ripl_CreateMask
#2 0x93d8d47f in RIPLayerSymmetricConvolve
#3 0x93d8dc0b in RIPLayerGaussianBlur
#4 0x93da795a in rips_s_BltShape
#5 0x93d74939 in ripc_Render
#6 0x93d7d7c4 in ripc_DrawPath
#7 0x94057a67 in CGContextDrawPath
#8 0x940a5726 in CGContextStrokePath
#9 0x95678b99 in -[NSBezierPath(NSBezierPathDevicePrimitives)
_doUserPathWithOp:inContext:]
#10 0x95678cb2 in -[NSBezierPath stroke]
What was the specific kind of crash (e.g. EXC_BAD_ACCESS)?
It's possible there's a byte-alignment issue, which would produce a
different exception than a buffer overrun.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list ([email protected])
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]
