• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
proliferating CFURLCache worker threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proliferating CFURLCache worker threads


  • Subject: proliferating CFURLCache worker threads
  • From: Martin Wierschin <email@hidden>
  • Date: Mon, 21 May 2012 20:34:42 -0700

Hello everyone,

Does anyone know anything about "com.apple.CFURLCACHE_work_queue" and how many of these queues/threads should be running at once? Normally I wouldn't care about such a detail, but I have several collected crash reports where these threads are proliferating (sometimes into the hundreds). 

All these threads look like this:

Thread 89:: Dispatch queue: com.apple.CFURLCACHE_work_queue
0   libsystem_kernel.dylib         0x93609c5e semaphore_wait_trap + 10
1   libdispatch.dylib              0x975c34e4 _dispatch_thread_semaphore_wait + 25
2   libdispatch.dylib              0x975c2628 _dispatch_barrier_sync_f_slow + 121
3   libdispatch.dylib              0x975c273c dispatch_barrier_sync_f + 37
4   libdispatch.dylib              0x975c28c4 dispatch_sync + 45
5   com.apple.CFNetwork            0x9b0f73de _ZL21_CFURLCacheDeallocatePKv + 234
6   com.apple.CoreFoundation       0x9508e1d1 CFRelease + 577
7   com.apple.CFNetwork            0x9b059ee1 ProcessCacheTasks(__CFURLCache*, bool) + 321
8   com.apple.CFNetwork            0x9b059715 _ZL24_CFURLCacheTimerCallbackPv + 721
9   libdispatch.dylib              0x975bffc9 _dispatch_call_block_and_release + 15
10  libdispatch.dylib              0x975c194f _dispatch_queue_drain + 224
11  libdispatch.dylib              0x975c17f4 _dispatch_queue_invoke + 47
12  libdispatch.dylib              0x975c0ffc _dispatch_worker_thread2 + 187
13  libsystem_c.dylib              0x98b31b24 _pthread_wqthread + 346
14  libsystem_c.dylib              0x98b336fe start_wqthread + 30

None of these threads are directly crashed. The crash is always some other thread, which I think occurs because the process is running out of file descriptors. An example I've seen more than once:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                            0000000000 0 + 0
1   com.apple.opencl               0x017501fe PlatformLoadDevice + 1722
2   com.apple.opencl               0x0174f553 PlatformInitCLCPU + 66
3   libsystem_c.dylib              0x98b2f487 pthread_once + 76
4   com.apple.opencl               0x0174f4b1 PlatformInitCL + 61
5   com.apple.opencl               0x0174f787 clGetDeviceIDs + 223
6   com.apple.opencl               0x01750f20 clCreateContextFromType + 65
7   com.apple.CoreImage            0x9a379136 ___createCPUclContext_block_invoke_0 + 67
8   libdispatch.dylib              0x975c3c27 dispatch_once_f + 50
9   libdispatch.dylib              0x975c3bf0 dispatch_once + 31
10  com.apple.CoreImage            0x9a375ce4 -[FEOpenCLContext initWithOptions:] + 710
...
45  com.apple.HIToolbox            0x97ab116b HIView::Draw(short, OpaqueGrafPtr*, unsigned long) + 81
46  com.apple.HIToolbox            0x97ab1533 HIView::Render(unsigned long, CGContext*) + 45
47  com.apple.HIToolbox            0x97a46ebb WindowData::PrepareForVisibility() + 137
48  com.apple.HIToolbox            0x97cd0fb7 _HIWindowPrepareForVisibility + 29
49  com.apple.HIToolbox            0x97bde7c5 _ZL8DrawMDEFP14MenuSelectData7CGPoint + 698
50  com.apple.HIToolbox            0x97bded50 _ZL11DrawTheMenuP14MenuSelectDataPP9__CFArrayhPh + 622
51  com.apple.HIToolbox            0x97bdf11e _ZL11MenuChangedP14MenuSelectDatahh + 608
52  com.apple.HIToolbox            0x97a4d949 _ZL15TrackMenuCommonR14MenuSelectDataPh + 1235
53  com.apple.HIToolbox            0x97be29a4 _ZL14MenuSelectCoreP8MenuData5PointdmPP13OpaqueMenuRefPt + 420
54  com.apple.HIToolbox            0x97a49bde _HandleMenuSelection2 + 636
55  com.apple.HIToolbox            0x97a4995d _HandleMenuSelection + 53
56  com.apple.AppKit               0x001cedbc _NSHandleCarbonMenuEvent + 302
57  com.apple.AppKit               0x0015f6c6 _DPSNextEvent + 2196
58  com.apple.AppKit               0x0015e942 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
59  com.apple.AppKit               0x0015acb1 -[NSApplication run] + 911
60  com.apple.AppKit               0x003ebbd9 NSApplicationMain + 1054
61  com.company.MyApp            0x00005dc1 main + 30
62  com.company.MyApp           0x00001fc5 start + 53

I don't know what that CoreImage/opencl stuff does, but my suspicion is that my app is running out of a limited resource. Allocated RAM isn't very high, so my best guess is file descriptors, which is why I'm suspicious about all the CFURLCache threads.

Some additional information: I'm using WebKit (indirectly via NSAttributedString's HTML loading methods) to import many HTML files. Each HTML load is wrapped in an autorelease pool, and I've run leaks (and done heapshot analysis) without turning up any mismanaged resources on my part. So it seems perhaps my HTML import requests are outstripping WebKit/CFURLCache's ability to cleanup after itself.

Does anyone have any thoughts on this situation?

Thanks for any thoughts or advice,
~Martin

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: proliferating CFURLCache worker threads
      • From: "Quinn \"The Eskimo!\"" <email@hidden>
  • Prev by Date: Re: EADDRNOTAVAIL after opening a number of sockets
  • Next by Date: Re: proliferating CFURLCache worker threads
  • Previous by thread: Re: EADDRNOTAVAIL after opening a number of sockets
  • Next by thread: Re: proliferating CFURLCache worker threads
  • Index(es):
    • Date
    • Thread