WTF, iTunes?

Dear Lazyweb, why is my iTunes spending so much of its time with a hypnowheel under aeProcessAppleEvent?

It seems like, for the last 4-6 months at least, iTunes goes completely out to lunch ("Not Responding", 100% CPU) dozens of times a day for minutes at a time. When I take a sample with Activity Monitor, the backtrace always looks like this, under aeProcessAppleEvent → dispatchEventAndSendReply, suggesting that it's sending an AppleEvent and hanging waiting for a reply... or maybe sending repeated events like crazy.

I've tried quitting every other app that might be trying to interact with iTunes (Last.FM, etc.) and it still happens. I'm not sure how to tell what app it's trying to send this event to, if that is in fact what's going on.

Any ideas?

2179 RunApplicationEventLoop
  2179 ToolboxEventDispatcher
    2179 SendEventToEventTarget
      2179 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
        2179 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
          2179 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
            2179 SendEventToEventTargetWithOptions
              2179 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
                2179 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
                  2179 0x12516b
                    2179 SendEventToEventTarget
                      2179 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
                        2179 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
                          2179 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
                            2179 SendEventToEventTargetWithOptions
                              2179 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*)
                                2179 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*)
                                  2179 TEventHandler::EventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*)
                                    2179 HIStdAppHandler::HandleEvent(OpaqueEventHandlerCallRef*, TCarbonEvent&)
                                      2179 AEProcessEvent
                                        2179 AEProcessAppleEvent
                                          2179 aeProcessAppleEvent
                                            2179 dispatchEventAndSendReply(AEDesc const*, AEDesc*)
                                              2179 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*)
                                                2179 0x13a52f
                                                  2179 0x13a60c
                                                    2179 0x13a693
                                                      2179 0x360e28
                                                        2179 AEResolve
                                                          2179 iAEResolve
                                                            2179 InternalResolve(ObjRecord**, short, unsigned long, AEDesc*, unsigned char*, AEDesc*, unsigned char*)
                                                              2179 InternalResolve(ObjRecord**, short, unsigned long, AEDesc*, unsigned char*, AEDesc*, unsigned char*)
                                                                2179 iCallAccessor
                                                                  2179 TryAccessor(HandlerTable*, iCallAccessor_EnvRec*)
                                                                    2179 0x360986
                                                                      2179 0x360484
                                                                        2179 0x361e82
                                                                          2179 0x3814aa
                                                                            2179 0x36218f
                                                                              2177 0x362463
                                                                                1299 0x38cb41
                                                                                  1264 0xf9100
                                                                                    772 0xf914a
                                                                                      653 0xf936d
                                                                                        470 0x5e815
                                                                                          197 0x56d47
                                                                                            99 0x2ddc
                                                                                              95 __bzero

Previously.

Tags: , , ,

19 Responses:

  1. richard says:

    Rather than just quitting last.fm.app, go into preferences, iPod, and uncheck "enable iPod scrobbling". On my 200+ GB library it will lock up iTunes for over 20 minutes. I'm not infront of that machine to confirm the activity monitor sampling is the same when iTunes is locked, but the behavior is similar.

    Also check for plugins in ~Library/iTunes/iTunes Plug-ins/

  2. Steve Kalkwarf says:

    You can set an environment variable which will cause the OS to spew AppleEvent info into your console. Maybe that will help you find the culprit?

    http://developer.apple.com/library/mac/technotes/tn2004/tn2124.html#SECAE

  3. macnlz says:

    Can you check /Library/Logs/DiagnosticReports and ~/Library/Logs/DiagnosticReports for any .spin or .hang reports for iTunes? I'd be interested in taking a look.

    • jwz says:

      Nothing about iTunes in there...

      • macnlz says:

        How long does it spin for? If it's long enough, you could try creating such a log manually by running spindump on the command line, the moment the issue appears.

  4. javierrgz says:

    Is Genius on? If it is, kill it now. Fast. It's an incredible resource hog. See if the problem persists.

  5. Tim says:

    IIRC, the calls in question indicate that it's receiving AppleEvents, not sending them.

    • hattifattener says:

      Yeah, I agree, it's processing / responding to something. The "Resolve" functions are also part of the (old, Carbon) aevt handling/interpreting mechanism. I'd say, turn on AEDebugReceives like Steve Kalkwarf suggests and see what event is causing it to lock up.

  6. Lloyd Wood says:

    iTunes is finally ready to replace Flash.

  7. spoonyfork says:

    Delete all smart playlists.

  8. Dennis says:

    I hope you've filed a bug with Apple in regards to this behavior -- I've had similar issues and I've put a few bugs in as well.

    I suspect that you probably have a large library. My own library has 35k songs, along with countless podcasts, videos and, of course, apps. I've never seen a report like this without the user having a large library. Though, I could be wrong and you only have a few hundred songs :)