Re: inconsistent crash drawing a string in a custom browser cell
Re: inconsistent crash drawing a string in a custom browser cell
- Subject: Re: inconsistent crash drawing a string in a custom browser cell
- From: Aki Inoue <email@hidden>
- Date: Wed, 7 Jun 2006 13:56:29 -0700
Graham,
If I'm reading the crash log correctly, it's crashing because -
[NSUserDefaults objectForKey:] message is being sent to an invalid
object. The object is queried right before the invocation via +
[NSUserDefaults standardUserDefaults]. I suspect stack corruption of
similar situation.
As Shawn explained, AppKit's UI objects are generally considered not
to be safe from multi-thread accesses.
Aside from the thread-safety issue, you appear to be updating
individual cells from multiple threads.
Probably it's extremely inefficient especially when you're updating
hundreds of cells like this.
Aki
On Jun 7, 2006, at 1:04 PM, Graham wrote:
I am running Tiger 10.4.6.
I placed the crash log on my website since it is 103k: http://
gragsie.com/FlickrFinder/Flickr Finder.crash.log
Interesting you have over 100 threads going in your application
with most of them in -[ThumbCell loadAsynchronously]. I assume you
just fork threads for each ThumbCell you have?
I strongly recommend that you switch to using a thread pool for
such asynchronous activity. Really no need to have that many
threads loading (what I assume is remote) information and
triggering its display. I bet things would perform better if you
limit the thread pool to just a few threads (seldom more then 10
should be needed). Depending on the size of the data requested, end
users bandwidth, and target servers load having that many loads
going at the same time can easily degrade performance.
Also I notice that those secondary threads are updating the UI. In
general the UI should only be updated from the main thread (thread
0). This may be causing the crash you are hitting.
It is hard to tell from the backtraces if you are taking the proper
steps to ensure you can update the UI from a secondary thread (the
fact that many are sitting waiting for a view hierarchy lock
implies you aren't... well at least they shouldn't be sitting their
if you did the proper locking before asking the cell to draw).
Personally I recommend you only update your UI from the main
thread, consider using -[NSObject
performSelectorOnMainThread:withObject:waitUntilDone:] from your
secondary threads.
You could also look at using just one thread to do your async
loading (could even do it on the main thread depending on the
load). In this secondary thread you could run a runloop and
schedule loading callbacks on that runloop... you can have multiple
loads outstanding that way while only having a single thread doing
the final data shuffling.
-Shawn
_______________________________________________
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
_______________________________________________
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