AESendMessage() doesn't deliver event sent to bundle ID address

Originator:bewebste
Number:rdar://12424662 Date Originated:03-Oct-2012 02:25 PM
Status:Open Resolved:
Product:OS X Product Version:OS X 10.8.2/12C54
Classification:Crash/Hang/Data Loss Reproducible:Sometimes
 
Summary:
Sometimes, an application will get into a state where sending an Apple event to that application using AESendMessage() will result in the event not being delivered to the target application, and AESendMessage() blocking in the client application until the timeout value is reached, at which time an errAETimeout error is returned. This does not happen if the event is sent specifically to the target applications kernel process ID, only when sending using the app's bundle identifier or creator signature. In Apple event nomenclature, having a target address descriptor with typeKernelProcessID works, but using typeApplicationBundleID does not work.

Steps to Reproduce:
Attached is a sample project which demonstrates the problem. Unfortunately, I have not been able to come up with a consistent method for getting the system into the state described above. It seems to have something to do with quitting and launching the application one or more times, but beyond that, I don't know what exactly the trigger is. Once you get into this state though, the steps below work to demonstrate the problem.

1. Build and launch the AppleEventTesting application.
2. In the "Bundle ID" text field, enter the bundle identifier of the application to be targeted by the Apple event. iPhoto's bundle identifier is the default, but it can be changed to something else.
3. Open the target application manually using the dock or Finder (the test app doesn't open it automatically, so it must be running first)
4. Click the "Send Event" button.
5. After the app becomes responsive again, check the "Use pid address" box, then click "Send Event" button again

Expected Results:
The following text should be output to the text view in the main window:

Sending event with settings: {
    sendAsync = 0;
    useCustomMachPort = 0;
    useGCD = 0;
    usePidAddress = 0;
}
Send: <NSAppleEventDescriptor: 'core'\'getd'{ '----':'obj '{ 'want':'prop', 'from':null(), 'form':'prop', 'seld':'pnam' } }>
Reply: <NSAppleEventDescriptor: 'aevt'\'ansr'{ '----':'utxt'("iPhoto") }>
Sending event with settings: {
    sendAsync = 0;
    useCustomMachPort = 0;
    useGCD = 0;
    usePidAddress = 1;
}
Send: <NSAppleEventDescriptor: 'core'\'getd'{ '----':'obj '{ 'want':'prop', 'from':null(), 'form':'prop', 'seld':'pnam' } }>
AESendMessage returned 0
Reply: <NSAppleEventDescriptor: 'aevt'\'ansr'{ '----':'utxt'("iPhoto") }>


Actual Results:
The first click of the "Send Event" button results in a hang until the timeout value of the Apple event is reached (in this project, we set it to 10 seconds). The second click works as expected. The following output is found in the window - note the "ASendMessage return -1712" output for the first event.

Sending event with settings: {
    sendAsync = 0;
    useCustomMachPort = 0;
    useGCD = 0;
    usePidAddress = 0;
}
Send: <NSAppleEventDescriptor: 'core'\'getd'{ '----':'obj '{ 'want':'prop', 'from':null(), 'form':'prop', 'seld':'pnam' } }>
AESendMessage returned -1712
Sending event with settings: {
    sendAsync = 0;
    useCustomMachPort = 0;
    useGCD = 0;
    usePidAddress = 1;
}
Send: <NSAppleEventDescriptor: 'core'\'getd'{ '----':'obj '{ 'want':'prop', 'from':null(), 'form':'prop', 'seld':'pnam' } }>
AESendMessage returned 0
Reply: <NSAppleEventDescriptor: 'aevt'\'ansr'{ '----':'utxt'("iPhoto") }>

Regression:
- This bug appears to only affect OS X 10.8.2, and I have not had any reports of the same problem on earlier versions.

Notes:
- The rest of the checkboxes in the sample app can be ignored for the purposes of this bug, they were all other variations I was trying in attempting to reproduce the problem, but in my experience they all give the same results.
- When this behavior does occur, it appears to be specific to just one application on the system. For example, if iPhoto gets in "the state" where it doesn't receive events sent via AESendMessage, another application such as iTunes will likely continue to work fine.
- The behavior does not appear to be related to the application _sending_ the event. I get the same behavior from both my own application and the test project, for example.
- While I have only gotten iPhoto in this state, I know at least one other developer has encountered this issue with their own application as the target. They filed this under bug 12396793. In their case, they were using typeSignature instead of typeApplicationBundleID, but otherwise the behavior they described was the same.
- The same behavior occurs in both 32 bit and 64 applications calling AESendMessage
- Quitting and relaunching the target application does not fix the problem. Logging out and back in again will usually clear things up so the target application can again receive Apple events.
- I filed an initial bug on this as number 12372422, before I had been able to reproduce the problem and produce this sample project.
- I suspect this bug may also be related to (now closed) bug 11458937, which I reported during the 10.8 developer preview period, but only dealt with "quit" events sent to applications.
- Events sent from a running AppleScript do not appear to suffer from this same problem.

03-Oct-2012 02:25 PM Brian Webster:
'AppleEventTesting.zip' and 'Mac Pro.spx' were successfully uploaded

Comments

repro steps for Console.app+Finder.app

I have several similar reports from my users and I was able to reliably reproduce the problem. The problem is somewhere in appleeventsd which gets into bad state. Shooting down the daemon fixes the issues temporarily.

Here are repro steps which lead to blocked appleeventsd (not always but very often):
0. launch Finder.app
1. in Console.app use "Reveal in Finder" on some .crash or .hang items (try at least two)
2. in Terminal.app execute: open .
3. in Terminal.app execute: osascript -e "tell application "Finder" to quit"; sleep 1; osascript -e "tell application "Finder" to launch"
4. goto [1]

After several cycles Reveal in Finder stops working. Also Archive Utility spawned by duble-clicking a zip file in Finder becomes unresponsive since then. Reveal in Finder from spotlight stops working and bunch of other apps which depend on the same mechanism.

Related info: https://getsatisfaction.com/binaryage/topics/totalfinder_and_archive_utility_not_playing_nice

By antonin.hildebrand at Oct. 3, 2012, 11:27 p.m. (reply...)

very common in iTunes

Just wanted to chime in to say that my app, FLACTunes (itunes.apple.com/us/app/flactunes/id517984121?mt=12) is suffering from this issue. Upon converting FLAC files, it attempts to add them to iTunes. iTunes seems to get in this "weird state" very, very often. The EyeTunes library (https://github.com/kgn/EyeTunes) test program can be used to verify this.

By vertespain at Oct. 12, 2012, 8:51 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!