Re: Serious crash from setNeedsDisplayInRect:
Re: Serious crash from setNeedsDisplayInRect:
- Subject: Re: Serious crash from setNeedsDisplayInRect:
- From: j o a r <email@hidden>
- Date: Wed, 9 Feb 2005 14:14:16 +0100
I understand that this is test code, so it might be weird for that
reason - but I have to ask:
* What is the point of spawning a secondary thread, when the only thing
it does is to schedule something back to the main thread? You could
just as well use a timer on the main thread.
* What is the point of triggering "setNeedsDisplay:" like this?
Try setting a breakpoint in dealloc if you wonder why it's called.
j o a r
On 2005-02-09, at 12.27, Benjohn wrote:
Our application is crashing. I've built a small test case to recreate
our application's behaviour, and this appears to crash in the same
way. In summary, there seems to be a serious bug with
setNeedsDisplayInRect:.
The test project is very simple, it's an NSView subclass that launches
one worker threads to draw in to itself. I have placed the view's
implementation at the bottom of this mail, along with GDB's stacks for
the main thread and worker thread, and log output from the program
running. I'd be delighted to mail an archive of the project to anyone
who would like a look (I'll be putting it on to Apple's bug tracker in
a few minutes).
A few points:
* I've put logging in to the view's dealloc call. This seems to get
called for no reason I can see when the view is still visible.
Presumably this is "not a good thing", and leads to the BAD ACCESS
that happens. Why the view would be deallocated, I don't know. I can
only presume that it's being caused by the framework.
* If "performSelectorOnMainThread:withObject:waitUntilDone:" is called
with "waitUntilDone: YES", then the crash does not happen.
* The real application seems to crash sooner on G5 dual processor
machines than on G4 dual processor machines. We've not seen the crash
on single processor machines, but haven't tried hard to replicate it
on such systems.
* Sometimes the test project and real app will be stable for a while
(tens of minutes under various provocations). Sometimes they fall over
almost immediately.
Unless there's something stupid I'm doing (which would be great), is
there something wrong with Apple's framework? We think that we may be
able to replace our "performSelectorOnMainThread:..." call with one
that uses "waitUntilDone: YES". I would welcome other workaround
suggestions.
The other obvious workaround is to simply call
"setNeedsDisplayInRect:" from the worker thread, and this does not
crash the test project (so far...). However, we originally used this
approach, but found that some rects were being ignored. We found that
calling "displayRect:" directly from workers did not loose rects, but
did cause crashes. In our current code, the workers ask the main
thread to call "displayRect:", but as found here, this causes
intermittent crashes.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden