This is a read-only archive of the Mumble forums.

This website archives and makes accessible historical state. It receives no updates or corrections. It is provided only to keep the information accessible as-is, under their old address.

For up-to-date information please refer to the Mumble website and its linked documentation and other resources. For support please refer to one of our other community/support channels.

Jump to content

Deadlock in Mac client (10.6.8)


michaelrhanson
 Share

Recommended Posts

I am observing multiple hangs (Application Not Responding / beachball) failures of Mumble on a 2.4Ghz Intel Core 2 Duo iMac running OS 10.6.8.


In the Diagnostic Logs, I observe numerous .hang files. The stack trace appears to implicate a remote AppleScript call during the handling of Log::postNotification, variously called by MainWindow::msgTextMessage, MainWindow::msgUserState, etc.


Specifically, I see postNotification calling qt_mac_execute_apple_script, which works its way down through the OSA and UAS libraries, until it hits AESendMessage, which then goes into a semaphore spin inside sendToModernProcess. The application becomes nonresponsive and has to be force-terminated.


In a few of the .hang reports I can see re-entrant calls to the main loop in my stack, which sounds like it could be a source of deadlock. Specifically, I see MainWindow::msgUserState calling postNotification, working down through AppleScript to UASRemoteSend, then InternalComponentActive, then AEDefaultActiveProc -- which then calls WaitNextEvent, and goes off through the main event dispatch AGAIN on the same stack, and handles a MainWindow::msgTextMessage call, which works down to another AppleScript call. I don't know my way around the Mumble code, but having two calls to WaitNextEvent on the same stack sounds pretty weird to me, and a recipe for deadlocks.


Does this sound like anything somebody knows about? The problem is pretty immediate and fatal -- the client becomes unusable after several minutes, usually.


Thanks.

Link to comment
Share on other sites

Did some more digging: it looks like this code branch is the "GrowlHelperApp" apple event dispatch -- that is, on a pre 10.8 system, Mumble sends notifications to Growl instead of the system notification library.


So: I think I'm finding a deadlock in the Growl message handling on pre-10.8 systems. Anybody else seen that?

Link to comment
Share on other sites

 Share

×
×
  • Create New...