"(Not Responding)" problems in Leopard

  • Starting in Leopard, both a helper process and a daemon of ours have
    started to occasionally be tagged as "(Not Responding)" in Activity
    Monitor.  Unfortunately, I have no idea why.  My understanding is that
    that's supposed to stem from not responding to pings on the main run
    loop.  But samples of the processes show their main threads just
    happily spinning away in the main run loop.

    The daemon's main thread:

    > 652 Thread_2503
    > 652 start
    > 652 _start
    > 652 main
    > 652 -[NSRunLoop(NSRunLoop) run]
    > 652 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
    > 652 CFRunLoopRunSpecific
    > 652 mach_msg
    > 652 mach_msg_trap
    > 652 mach_msg_trap

    Purely unloaded; no reason it shouldn't be responding to pings.

    The helper's main thread:

    > 2197 Thread_2503
    > 2197 start
    > 2197 _start
    > 2197 main
    > 2197 -[NSRunLoop(NSRunLoop) runUntilDate:]
    > 2197 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
    > 2197 CFRunLoopRunInMode
    > 2196 CFRunLoopRunSpecific
    > 2182 mach_msg
    > 2182 mach_msg_trap
    > 2182 mach_msg_trap
    > 13 __CFMachPortPerform
    > 13 __NSFireMachPort
    > 10 -[NSConcretePortCoder dispatch]
    > 10 -[NSConnection handlePortCoder:]
    > 10 -[NSConnection handleRequest:sequence:]
    > 8 -[NSConnection
    > returnResult:exception:sequence:imports:]
    > 8 -[NSConcretePortCoder
    > sendBeforeTime:sendReplyPort:]
    > 8 -[NSMachPort
    > sendBeforeTime:streamData:components:from:msgid:]
    > 8 +[NSMachPort
    > sendBeforeTime:streamData:components:to:from:msgid:reserved:]
    > 8 mach_msg
    > 8 mach_msg_trap
    > 8 mach_msg_trap
    > 1 -[NSConnection dispatchInvocation:]
    > 1 -[NSInvocation invoke]
    > 1 __invoking___
    > 1 _CF_forwarding_prep_0
    > 1 ___forwarding___
    > 1 -[NSDistantObject
    > methodSignatureForSelector:]
    > 1 -[NSDistantObject
    > methodSignatureForSelector:]
    > 1 -[NSInvocation target]
    > 1 objc_msgSend
    > 1 objc_msgSend
    > 2 NSPopAutoreleasePool
    > 1 -[NSConcretePortCoder dealloc]
    > 1 NSDeallocateObject
    > 1 _internal_object_dispose
    > 1 free
    > 1 szone_size
    > 1 szone_size
    > 1 _CFRelease
    > 1 __CFArrayReleaseValues
    > 1 CFRelease
    > 1 -[NSConcreteData dealloc]
    > 1 NSDeallocateMemoryPages
    > 1 vm_deallocate
    > 1 mach_msg
    > 1 mach_msg_trap
    > 1 mach_msg_trap
    > 1 class_respondsToSelector
    > 1 class_respondsToSelector
    > 1 mk_timer_arm
    > 1 mk_timer_arm
    > 1 __spin_lock
    > 1 __spin_lock

    Some light DO traffic, but less than 1% of the samples.  Again, no
    reason I can see why it wouldn't be responding.

    As far as I know it's irrelevant, but for the record, the other
    threads in the daemon are spinning in a run loop or blocked on a
    semaphore; 0% CPU used.  The helper process's one other thread is
    almost entirely I/O bound, with a total ~30% CPU usage.

    Can anybody shed some insight on what the problem is?  As far as I can
    tell, the processes are being well-behaved, so I'm rather at a loss as
    to why this is happening...

    Thanks,
    br

    --
    Benjamin D. Rister
    President
    Decimus Software, Inc.

    http://www.decimus.net/
  • On Nov 11, 2007, at 8:17 PM, Benjamin D. Rister wrote:

    > Can anybody shed some insight on what the problem is?  As far as I
    > can tell, the processes are being well-behaved, so I'm rather at a
    > loss as to why this is happening...

    Only the Activity Monitor people would know for sure, but in my
    experience, the "not responding" appears if a task opened a connection
    to the window server, and then did not respond to "ping" Apple events.
    Does your task call NSApplicationLoad() or use any Carbon UI-related
    functions?

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • No Carbon UI functions, though plenty of Carbon FS functions.  No call
    to NSApplicationLoad(), either--my understanding is that that's only
    needed if you're trying to run a Carbon event loop and use Cocoa.

    I'm not particularly trying to avoid a connection to the window server
    (at least in the helper executable).  I do use some API that I noticed
    hooks up with the window server (NSWorkspace?  Launch Services?), so
    I'm mostly just trying to stay well-behaved and leave the main run
    loop clear to answer the pings.

    As a further bit of weirdness, I just noticed that it takes a while
    for Activity Monitor to get upset with the processes, and sometimes
    won't even ever flag them.  The daemon, for instance, will be just
    fine when launched and interacted with, and I'll just find it marked
    as not responding some time later when I happen to look (but still
    producing samples like the ones I already posted).

    This just gets more confusing by the day, and it's shaking our
    customers' confidence in the product to see the processes marked as
    hung. :-/

    Best,
    br

    On Nov 12, 2007, at 3:58 PM, Nick Zitzmann wrote:

    >
    > On Nov 11, 2007, at 8:17 PM, Benjamin D. Rister wrote:
    >
    >> Can anybody shed some insight on what the problem is?  As far as I
    >> can tell, the processes are being well-behaved, so I'm rather at a
    >> loss as to why this is happening...
    >
    >
    > Only the Activity Monitor people would know for sure, but in my
    > experience, the "not responding" appears if a task opened a
    > connection to the window server, and then did not respond to "ping"
    > Apple events. Does your task call NSApplicationLoad() or use any
    > Carbon UI-related functions?
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
    >
    >
    >

    --
    Benjamin D. Rister
    President
    Decimus Software, Inc.

    http://www.decimus.net/
  • On Nov 12, 2007, at 8:36 PM, Benjamin D. Rister wrote:

    > I'm not particularly trying to avoid a connection to the window
    > server (at least in the helper executable).  I do use some API that
    > I noticed hooks up with the window server (NSWorkspace?  Launch
    > Services?), so I'm mostly just trying to stay well-behaved and leave
    > the main run loop clear to answer the pings.

    I found out the hard way a while back that, if you try using
    NSWorkspace without calling NSApplicationLoad() first, then you're
    playing with fire. Apple might have changed things in Leopard so that
    NSWorkspace automatically sets things up, but in Tiger it didn't.

    > This just gets more confusing by the day, and it's shaking our
    > customers' confidence in the product to see the processes marked as
    > hung. :-/

    Unfortunately I think you're going to have to avoid using any AppKit
    classes in your background task.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • > I found out the hard way a while back that, if you try using
    > NSWorkspace without calling NSApplicationLoad() first, then you're
    > playing with fire. Apple might have changed things in Leopard so
    > that NSWorkspace automatically sets things up, but in Tiger it didn't.

    I reported a bug on this a while back; I haven't had a chance to try
    it but I think it's been fixed in Leopard.

    -Sam
  • Sam Stigler wrote:

    >> I found out the hard way a while back that, if you try using
    >> NSWorkspace without calling NSApplicationLoad() first, then you're
    >> playing with fire. Apple might have changed things in Leopard so
    >> that NSWorkspace automatically sets things up, but in Tiger it
    >> didn't.
    >
    > I reported a bug on this a while back; I haven't had a chance to try
    > it but I think it's been fixed in Leopard.

    This problem is in the opposite direction, however.  Tiger is OK with
    these processes, it's Leopard that's complaining.  Also, all actual
    NSWorkspace functionality is working fine and producing correct results.

    Nick Zitzmann wrote:

    > Unfortunately I think you're going to have to avoid using any AppKit
    > classes in your background task.

    I went through the helper app and commented out everything that
    depended on any framework outside the explicitly-approved list of
    daemon-safe frameworks at <http://developer.apple.com/technotes/tn2005/tn2083.html#SECFRAMEWORKCROSSRE
    FERENCE
    >, and quit linking against any of them.  Activity Monitor still
    flagged it as not responding after running for a while.

    Everything *works* from a functional standpoint.  And the fact that AM
    is fine for a while makes me think that the fundamental structure of
    the loops are probably OK--a daemon instance I started yesterday is
    still happily hanging out without a "not responding" tag, in fact.
    And now it seems that it still happens even without calling anything
    that's not daemon-safe.  Curiouser and curiouser.

    Best,
    br

    --
    Benjamin D. Rister
    President
    Decimus Software, Inc.

    http://www.decimus.net/
  • Am 13.11.2007 um 04:36 schrieb Benjamin D. Rister:
    > No Carbon UI functions, though plenty of Carbon FS functions.  No
    > call to NSApplicationLoad(), either--my understanding is that that's
    > only needed if you're trying to run a Carbon event loop and use Cocoa.

      Nope. NSApplicationLoad() is needed whenever you're calling AppKit
    functions and you're not using NSApplicationMain().

    Cheers,
    -- M. Uli Kusterer
    "The Witnesses of TeachText are everywhere..."
    http://www.zathras.de
  • On Nov 13, 2007, at 3:44 PM, Uli Kusterer wrote:

    > Am 13.11.2007 um 04:36 schrieb Benjamin D. Rister:
    >> No Carbon UI functions, though plenty of Carbon FS functions.  No
    >> call to NSApplicationLoad(), either--my understanding is that
    >> that's only needed if you're trying to run a Carbon event loop and
    >> use Cocoa.
    >
    > Nope. NSApplicationLoad() is needed whenever you're calling AppKit
    > functions and you're not using NSApplicationMain().

    Good to know, even if it doesn't seem to be the source of this
    particular problem (per my later response to Nick and Sam).

    Unfortunately, it seems that calling NSApplicationLoad() triggers a
    series of dialogs complaining about the command line arguments I
    passed to my tool.  (This is even though it doesn't take argc/argv as
    parameters--it must be getting them from somewhere else...)  How does
    one get NSApplicationLoad() to leave my arguments alone?

    Best,
    br

    --
    Benjamin D. Rister
    President
    Decimus Software, Inc.

    http://www.decimus.net/
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today