My original solution is to call:
[UIFont familyNames];
in the applicationDidFinishLaunching method to load the font database to avoid
the deadlock.
-Stevo
On Sep 16, 2010, at 3:26 PM, A.M. wrote:
>
> On Sep 16, 2010, at 5:54 PM, Stevo Brock wrote:
>
>> Great suggestion.
>>
>> Here's the full list of backtraces from the iPad (3.2.2)... Spin lock is in
>> Thread 1 at the end...
>>
>> Thread 1 (thread 12035):
>> #0 0x33af18a4 in spin_lock ()
>> #1 0x33af21aa in pthread_once ()
>> #2 0x33d795a2 in CGFontCreate ()
>> #3 0x33df21e0 in CGFontCreateWithDataProvider ()
>> #4 0x3414cb72 in AddFontsFromURLOrPath ()
>> #5 0x3414cc98 in Initialize ()
>> #6 0x3414d360 in GSFontInitialize ()
>> #7 0x33d78e12 in initialize_font_database ()
>> #8 0x33af21c8 in pthread_once ()
>> #9 0x33d78d46 in CGFontCreateWithFontName ()
>> #10 0x33d78d1e in CGFontCreateWithName ()
>> #11 0x33de8950 in CGContextSelectFont ()
>> #12 0x00041cf8 in -[SceneTextController drawGL:] (self=0x274b20,
>> _cmd=0x4b77c, offset={x = 0, y = 0}) at .../SceneTextController.m:162
>> #13 0x000404ee in -[SIGameHighScoreDisplayController drawGL:]
>> (self=0x2749c0, _cmd=0x4b77c, offset={x = 0, y = 0}) at
>> .../SIGameHighScoreDisplayController.m:109
>> #14 0x000128a8 in -[SceneController drawGL] (self=0x259280, _cmd=0x46df0) at
>> .../SceneController.m:196
>> #15 0x0001fabe in -[SceneTransitionPush drawGL] (self=0x267d40,
>> _cmd=0x46df0) at /.../SceneTransitionPush.m:152
>> #16 0x0001af76 in -[SceneViewController updateAndDraw:] (self=0x220dc0,
>> _cmd=0x46a33, timer=0x259420) at .../SceneViewController.m:674
>> #17 0x303b1eb8 in __NSFireTimer ()
>> #18 0x314d8d22 in CFRunLoopRunSpecific ()
>> #19 0x314d84e0 in CFRunLoopRunInMode ()
>> #20 0x3414e0da in GSEventRunModal ()
>> #21 0x3414e186 in GSEventRun ()
>> #22 0x32241430 in -[UIApplication _run] ()
>> #23 0x3223f95a in UIApplicationMain ()
>> #24 0x00029712 in main (argc=1, argv=0x2ffff5f0) at .../main.m:10
>
>
> I can confirm that this is a bug in Apple's font implementation- here is a
> sample program which exhibits the same characteristics:
>
> #include <pthread.h>
>
> pthread_once_t oncetoken = PTHREAD_ONCE_INIT;
>
> void once()
> {
> pthread_once(&oncetoken,once);
> }
>
> int main()
> {
> pthread_once(&oncetoken,once);
> }
>
> This program gets stuck on __spin_lock() in the same fashion as above. The
> bug is that a pthread_once()-initiated function is calling through to another
> method which calls pthread_once with the same once token (because the font
> database has not yet been created). For what it's worth, Linux also does not
> like nested pthread_once and will choke in the same fashion.
>
> Unfortunately, due to the nature of closed source software, there is nothing
> we can do about this...
>
> Cheers,
> M_______________________________________________
>
> 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/stevo%40monkey-tools.com
>
> This email sent to [email protected]
_______________________________________________
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]
