10.4.3 Breakage

I hear that 10.4.3 is causing issues with authentication and generating Applescript -1721 errors in my app and in others’ apps. Anyone seen this?

Can you be more specific?

Here’s the feedback I got. I can duplicate the issues. None of this happened with 10.4.2

ok, new machine, clean install of 10.4 and then combo’ed to 10.4.3

resize the output log for a cosmetic bug

when I ran repair permissions, I got a few of these:
applescript error -1762
but it seemed to work

in Installed Packages under Disk
when I clicked Go on a .pkg
I got the following:
AS Error:“/Library/Logs/machelpmate.log” may be a binary file. See it
anyway? (1)

A little more investigation has revealed that using “delay” causes immediate AppleScript errors. BIG Bug, unless I’ve been using delay wrong all these months.

I’m seeing the same thing, but only in my AS Studio apps, not in my standalone scripts. It also appears to be somewhat random (it doesn’t happen every time I call the delay command but it does happen far too often). Wrapping the delay calls in a try block doesn’t suppress the error. Anyone have some ideas? (Using a sleep command through a do shell script call makes my app seem kind of jerky – it doesn’t delay the specific amount of time I call but varies due to the inefficiencies of calling the shell). I guess I could also use a call method to access an NSTimer in Obj-C but again, I’d rather have a good AppleScript solution.


OK, this isn’t optimal but it seems to have solved the issue in my AS Studio apps that use the delay command in Mac OS X 10.4.3 (incidentally, this also seems to work for the do shell script command). First, everywhere I had used the delay command, I substituted a subroutine so in the future, if there is a better fix, it just requires adjusting one line instead of all the incidences of the command. In the subroutine, I used the run script command which I believe then executes the script in its own thread outside of the AS Studio app’s thread:

my run_delay(1.5)

on run_delay(the_delay)
		run script ("delay " & the_delay)
	end try
end run_delay

This seems to run much smoother than using a do shell script sleep command or call an Obj-C method to delay it.


Well that’s a good solution, but I’d rather like to know how we got ourselves into this situation. It’s funny, since I’ve started developing (I’m 41, so I’m coming into it at a late age) I never thought I’d feel the emotions I’ve felt when using AppleScript Studio. It’s really quite a roller coaster, with a low point yesterday. I have some pretty good ideas but now I’m wondering if AppleScript Studio is the proper foundation to develop those ideas. If a point release of an OS can cause such breakage, I am very concerned about the long term and short term viability of my apps. What if I was sick?

I’m trying hard to wrap my mind around this one. Could it be a compiler problem? An installer corruption problem? Could apple have dropped the ball? Seems unlikely, but anything’s possible. :rolleyes:

Firstly, I don’t see any of these reported behaviors in scripts or ASS projects. Jon, you mention that it’s “random”… how random? Should I be running my app 3 times or 300 times to see an occurance of this problem? Either way, it’s unacceptable, but I have yet to see shell scripts or delay commands break. Apple’s PR statement regarding the release of 10.4.3 lists updates to the do shell script, delay, and system info commands. I didn’t realize that they were broken. Seems to me that they de-fixed them. Perhaps they misunderstood and had them “fixed”… i.e NEUTERED them. :lol:

As I said, I haven’t been able to reproduce these problems. I’ve run old projects and created new ones with no success… uh, I mean failure. Does anyone have any code that errors much or all of the time that I could try? In an article at macfixit they mention a few things that could make an installation go bunk. I can attest to surfing the web, managing my desktop and files, and running many applications while I downloaded the 100m beast. I used software update, so I may have been in bed during the actual install part, though. :wink: And since it’s working for me, I obviously don’t have any permissions or cache conflicts that they claim may be part of the problem.

Since apple claims to have just “fixed” all the things that went wrong in this release, I find it more plausible that they failed to test their “fixes” before sending them out to the millions of people in world that will be significantly effected by them. Hard to believe, but also hard to deny that it looks pretty bad for apple, right now.

If anything, I might recommend that people who have not yet updated download the standalone version in apple’s download section rather than via software update… just to be sure. I usually do this anyways, so I always have a copy of the installer on file, just in case.

deanshavit, remember that programming is and always will be wrought with pitfalls and frustrations. You will always have obstacles and challenges to overcome. In my opinion, it is your ability to overcome them and continue working that separates a developer from an end-user. No matter which language you use, there will be errors and quirks, which you alone will be responsible for accounting for. If this really is a problem for everyone (which it appears it may become) then apple will ultimately be held accountable for fixing it. If anything, they’ll just be pressured to put it back the way they found it. As Jon eluded, there will be solutions… however uncomfortable and unconvenient for us. There will be workarounds and hacks that we can effectively use to get around this until they are fixed. Responsible application development requires constant and somewhat permanent dedication to the project… not just a one time investment in a whim. OS’s and environments change, and we as developers must realize this and be willing to accomodate… not just today, but indefinitely. From applescript to obj-c to perl to html, things change and new bugs and protocols get introduced. Applescript is actually pretty stable and predictable, and has a long history, making it a pretty good candidate for my platform of choice. Don’t shy away because one thing’s been changed for 2 days… especially a thing that will likely be explained and remedied in a short period of time.

If anyone has code that they think will break on my machine, please send it on.

Jobu, thanks for the encouraging words. However, it’s one thing to have some new incompatibilities due to enhancements or improvements, but when your error handling doesn’t work, and when the error’s undocumented (-1762 is an Apple Event Error doucmented NOWHERE), and the seeds of 10.4.3 DIDN’T cause this problem, one begins to wonder if they’re using the correct tool for the job, especially when they are using shell commands running with root privs!

Hmm, when I create a new AS Studio app and test the delay command, it works without incident but apps created before the Mac OS X 10.4.3 update do exhibit the behavior (even if I completely clean the project before building). Using the “run script” hack seems to work on my legacy apps (I updated several of them this morning and have had a couple thousand downloads and no reports of the error when I was getting a lot of reports yesterday).

For the record, I always download the complete combo updater from Apple, repair permissions (before and after installation), make a backup before installing, quit any running processes, and restart immediately after installing an update. I don’t have any third-party OSAX installed and my third-party system extensions are really minimal (no haxies).


Are you saying the AS application showed the same behavior when the project was created on a pre-10.4.3 system and then recompiled on 10.4.3 system or when you cleaned the project and recompiled, the system you did the build on was still 10.4.2?

Both. The app built prior to Mac OS X 10.4.3 showed this behavior. Same project opened in Xcode 2.1 on Mac OS X 10.4.3, cleaned and re-built also shows the problem. At first (as I posted above), I thought that new projects were not exhibiting this issue but, on making a more robust test project on my 10.4.3 system, I have been able to recreate the error in a new app but not with the delay command on its own. The issue, I believe, is some sort of interaction between the delay command and an app’s idle handler (assuming it has one). Somehow the idle command wants to idle but, if there is a “delay” command in the same thread, the error raises its ugly head. This happens sporadically, that is not every time the delay command is called, but it does happen frequently and reproducibly. Using an idle handler in a regular AppleScript application saved as a stay-open app doesn’t cause the error. In any event, when I use the “run script” method I posted above, I no longer get the error even with AS Studio apps with idle handlers.


Jon’s right on both counts. First, it is the presence of the idle handler and the naked delay command (I’ve since put it into a separate handler) that causes the error. From what I’ve learned, the undocumented -1762 error means something along the lines of “Can’t FInd Scripting Component.” I was alterted to the problem by couple of my beta testers who had updated to 10.4.3, using builds of my app that I’d made under 10.4.2. That’s why I sort of got concerned, not because it happened with the 10.4.3 updated and app I built under 10.4.3, but because the problem surfaced when people upgraded, which potentially could have caused bigger problems. It was that shock of finding out that my app wasn’t forward-compatible that sort of led me to question whether AppleScript Studio was the right platform for me to be developing on, as well as Jobu’s wise lecture in response. In working within this community, finding out what the problem and solution have been in just a couple of days is very encouraging, as well as knowing that the delay issue isn’t a major one and again, I have to say what a great resource MacScripter is, thanks to all who have a hand in running it and all the contributors!

PS.: In my opinion, the issue isn’t with Xcode or some dreadful combination of the delay and idle commands, which have worked seamlessly together since they were introduced to AppleScript, from all I can gather. It seems that the problem is with the build of the OS itself, most likely with the standard AppleScript additions. I might take some time and ktrace the process to see if I can get any more specific information.

Has this issue been resolved in 10.4.4?


Hmmm. This is getting very interesting though truly frustrating. I am on 10…4.4 and upgraded recently to Xcode 2.2.

I’ve been having problem recently with the delay command and gotten around to simply removing them where the problem is encountered. I have been able to make my app work when I do that.

But wait…there are also threads in this forum that are related I think. It’s quitting from the AS Studio app that had given me the -1762 error (can’t find the scripting component) and things just seem to circle back and forth for the app that’s trying to quit. Another poster (jamdr) had problem with Signal 11 (SIGSEGV) and I had another addition later on …Signal 10 (SIGBUS) error.

All these had not happened before… but of course, sometimes I attribute it largely to my own sloppy programming. For instance, I managed to remove the above signal 10/11 errors and make my app work by unchecking the “Release when closed” option of some windows in the IB. On the other hand, why did it work before with that option on? Little did I attribute it to the fact that Apple might have “screwed” things up for me. Tsk, tsk.

Please keep updating this thread so we will know where our apps stand.

Many thanks.

archseed :expressionless:


Instead of:

my run_delay(1.5)

on run_delay(the_delay)
run script ("delay " & the_delay)
end try
end run_delay

You can just add the handler to intercept the delay command:

delay 1.5

on delay the_delay
run script ("delay " & the_delay)
end try
end delay

I’m getting trouble with the sleep command also. Pre-xcode.


So the dreadful and utterly silly delay bug survived the 10.4.5 update… What to do? If you are working with short delays, the approaches given here just don’t cut it (since the execution of the shell script will suspend the delay). I found a command in the Tcl framework called Tcl_Sleep which solved the problem. Man page says:

Add the framework, write an appropriate method (I called mine “delay:” and added it to my “methods.m” file), then call the method with something like this:

on do_delay(the_delay)
	call method "delay:" of class "methods" with parameter (the_delay * 1000)
end do_delay

To my methods file I added these lines:

Works great for me.

This worked for me! Not optimal (it really sux having to do it at all)

For the record, 10.4.5 on a 20" Intel iMac

Thanks Jon!


Do we still need the workarounds? After upgrading to XCode 2.4 I don’t have this problem anymore (on an Intel Mac running 10.4.8). Anyone know if this issue is still present on earlier OSs/PPCs, eg. if it was a bug in Xcode or the OS itself? (I haven’t checked this in a long long time, I just got used to throwing in a “run script” whenever I need a delay… Just realized now that perhaps I don’t have to anymore…)