Re: NSColor Deadlock bug?
Re: NSColor Deadlock bug?
- Subject: Re: NSColor Deadlock bug?
- From: String <email@hidden>
- Date: Sat, 7 Feb 2004 09:47:27 -0600
On Feb 6, 2004, at 8:28 PM, J. Nicholas Jitkoff wrote:
>
I have been tracking a bug that makes my app hang for the last few
>
weeks.
That's al long time... did you try "Force Quit" =8)
>
It it appears that many different types of drawing will cause deadlock
>
if they happen at the same time as another thread is looking up a
>
theme color.
>
>
>
405 -[NSTableView drawRect:]
>
405 -[NSTableView drawRow:clipRect:]
>
405 -[NSImageCell drawWithFrame:inView:]
>
405 +[NSColor controlShadowColor]
>
405 -[NSDynamicSystemColor initWithSelector:]
>
405 -[NSDynamicSystemColor recacheColor]
>
405 -[NSColor blendedColorWithFraction:ofColor:]
>
405 -[NSCatalogColor colorUsingColorSpaceName:device:]
>
405 -[NSColorList colorWithKey:]
>
405 -[NSColorList _loadColors]
>
405 -[NSColorList _parseArchivedList:]
>
405 -[NSColorList
>
_decodeWithoutNameWithCoder:newStyle:]
>
405 -[NSUnarchiver decodeValuesOfObjCTypes:]
>
405 _decodeValueOfObjCType
>
405 _decodeObject_old
>
405 -[NSColor initWithCoder:]
>
405 +[NSCatalogColor
>
newWithCoder:zone:]
>
405 +[NSColor
>
colorWithCatalogName:colorName:]
>
405 +[NSColor
>
selectedMenuItemColor]
>
405 -[NSDynamicSystemColor
>
initWithSelector:]
>
405 -[NSDynamicSystemColor
>
recacheColor]
>
405 GetThemePattern
>
>>>
Here NSAppKitImgLock is grabbing a mutext presumably for image/drawing
code... And its blocked because someone else had the semaphore. Another
app maybe ?
>
405 _NSAppKitImgLock
>
405 -[NSRecursiveLock
>
lock]
>
405 _pthread_cond_wait
>
405
>
semaphore_wait_signal_trap
>
405
>
semaphore_wait_signal_trap
>
>
>
thread 2
>
>
405 -[NSImage representations]
>
405 -[NSImage _expand]
>
405 -[NSImage _expandRep:]
>
405 -[NSImage lockFocus]
>
405 -[NSCachedImageRep
>
_initWithSize:depth:separate:alpha:allowDeep:]
>
405 _NXAllocateImageCache
>
405 -[NSView lockFocus]
>
405 -[NSImageCacheView lockFocusIfCanDraw]
>
405 -[NSWindow _threadContext]
>
>>> Here NSWindow is doing an NSAppKitLock. Now... my question for
someone w/app kit doco is this method trying to lock all of AppKit ? or
taking more than one semaphore. etc ?
405 _NSAppKitLock
>
405 -[NSRecursiveLock lock]
>
405 _pthread_cond_wait
>
405 semaphore_wait_signal_trap
>
405 semaphore_wait_signal_trap
I'm trying to figure out if 'thread2' has locked a sem. needed by
another process (call it thread3)- one that posses the sem. needed by
NSAppKitImageLock - "thread 1". Then thread 3 will block on thread2
which is blocking thread1 which is blocked by thread3. If the process
containing "thread 3" is another app, it may look like the problem is
w/in the app containing threads 1 & 2.
Apple, Is there doco avail. for AppKit ?
One thing to try would be to create your own semaphore to control
access the the resource.
From Obj-C doco:
"The @synchronized() directive takes as its only argument any
Objective-C object, including self. This object is known as amutual
exclusion semaphore or mutex . It allows a thread to lock a section of
code to prevent its use by other threads. You should use separate
semaphores to protect different critical sections of a program. Its
safest to create all the mutual exclusion objects before the
application becomes multithreaded to avoid race conditions."
HTH.
-string
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.