Script debugger crashed

Script Debugger Beta Testing
#1

Shane and Mark,

I made a change to this post on 1/19/2018 in the second to the last paragraph.

Before
I quit the two background.apps and reran the same test I had done using SD. This time the script ran with no errors.

After
I quit the two background.apps and reran the same test I had done using SD. This time the script ran in ScriptDebugger with no errors.

The files background.scpt, foreground.scpt, background2:background.app, and background1:background.app were created on a Mac running El Capitan and the scripts were written and run in Script Editor. The actual test was run under Mac OS X Sierra.

The script called “background” was exported in “Script Editor” to create two Applets called background, one file in each of the 2 folders. This means the 2 new applets should be identical. The background.scpt in the top level of the folder hierarchy was not used during the test. Each of the scripts were put into different folders and the following structure was created in Finder:

  • background.scpt
  • foreground.scpt
  • background 2 folder
    • background.app
  • background 1 folder
    • background.app

foreground.scpt contained the following script

use scripting additions

tell application "System Events"
	application file of every process whose name = "background"
end tell

The test consisted of launching background.app in the folders “background 2” and “background 1” on a Mac running “El Capitan.” Then the foreground.scpt was run under “El Capitan” using “Script Editor.” This ran successfully.

The scripts and applets were then zipped and sent to a Mac running “Sierra”. Then “foreground.scpt” was run under Sierra using “Script Debugger” and a problem occurred. An internal error dialog came up in SD, the “Details” button was clicked and the text was copied, the crash button was clicked, a Mac OS crash report dialog came up, then the SD crash information was copied. I put all the reports into a zip archive called “Crash related files.zip”

Error dialog

Error reports

  • Details button.txt - Contains the text displayed after the “Show Details” button was clicked in the internal error dialog.
  • OSX crash.txt - Contains the OS X crash report from the error that was generated.
  • ScriptDebugger crash.txt - Contains the ScriptDebugger crash report from the error that was generated.

I ran the same script in “Script Editor” in the same way I ran it when using SD and it worked without a problem. It returned the following output:
returned {alias “1A795D23-27DA-4E87-B29B-B2A76CDB87C4:d:background.app:” of application “System Events”, alias “BF169D0F-FE7F-4BDA-9C86-C35F17E32994:d:background.app:” of application “System Events”}

I quit the two background.apps and reran the same test I had done using SD. This time the script ran in ScriptDebugger with no errors.

Part of the reason for trying this type of test was the fact I noticed a while ago that when I tried to differentiate between two different running Applets using AppleScript that had the same name the script could not differentiate between the applets. I thought it was a problem related to AppleScript. But I discovered today that “Script Editor” could differentiate between the applets. So this appears to be a problem specific to “ScriptDebugger.” SD’s ability to deal with Applets that have the same name has not worked for a while. For some reason I decided it was an AppleScript problem.

Crash related files.zip (249.5 KB)

#2

Thanks for the bug report. I can reproduce the problem here. There are multiple failures at play. While I’ve been able to fix the Script Debugger crashes for the next build, there are AppleScript behaviours that don’t make any sense and which prevent Script Debugger from properly display the result of your example script.

When I launch one of the background apps, and then launch the second, the second one appears strongely in the Dock:

59 PM

or

21 PM

Something about having two apps with the same bundle ID running from different locations is giving the system kittens.

#3

Apple does say every bundle ID must be unique. There is lots of Apple software that requires on all bundle IDs to be unique. Anything looking through a list trying to find some information for something with a particular bundle id might get the wrong item because the first bundle ID found went with the wrong item because the search just took the first one it found.

I thought this was a good thing to test since the user can so easily specify a bundle ID in SD 7. Someone could create an applet with an ID and then next week create another Applet with the same ID. While the second applet might work at that time it could fail later when the first applet is launched. I’m not sure how many scripters are familiar with the reverse domain name structure of bundle IDs. Sometimes I’ve wondered if ScriptDebugger should check the structure of the bundle IDs entered to make sure it is in a revered domain name structure. I can enter just “dog” into the Bundle ID field of the Resource pane and when I check the Info.plist for the script it shows “dog” for the Bundle identifier. I’ve actually tried that because I wanted to see what it did for invalidly formatted bundle IDs. Incorrectly formatted bundle IDs would probably cause problems using ASObj-C.

Thanks for all the great things in SD 7 :slight_smile:

Bill

#4

And they should. But for @BillKopp and anyone following, there’s another factor involved here: the paths you’ve posted show that Gatekeeper Path Randomization is in action, making the apps behave like they’ve been launched from mounted disk images.

That’s what happens if you download a file and launch it using Open on the Finder contextual menu under 10.12 and later. And it can cause other script failures, too.

The way to stop an app launching that way is to first move it to a different folder, and then use Open. If you had done that, you probably wouldn’t have seen any problems.

#5

Thanks for posting about moving the applet :slight_smile: I didn’t know moving it would help.

Bill