I’ve had a crash today in Yosemite, and was able to reproduce at home. It’s a bit hard to reproduce, but here’s the deal.
Open a dictionary window for System Events. Click on the explorer button. Click on the Launch button in the dialog that appears. While the explorer is waiting to load values, click on the Safari icon in the doc (not sure it has to be Safari, but that’s what did it for me both times).
SD quits unexpectedly.
But, here’s the thing, if System Events has been running recently then there is no delay in loading the values and it won’t crash. So basically this only happens once every scripting session. After System Events clears itself up you can try again (not sure how long that takes)
I tried to reproduce this under El Capitan 10.11.6 using SD 6.0.3. “SystemEvents” dictionary is a different one in that it’s dictionary is stored in the system folder at “System:Library:CoreServices:System Events.app:Contents:Resources:SystemEvents.sdef” The .sdef and therefore the dictionary is always available. A dictionary for “System Events” doesn’t get stored in the “~Library:Caches:Script Debugger:” folder where SD stores it’s dictionary caches. This is true whether the “Cache generated dictionaries” preference is set “on” or “off” in the “Dictionary” tab of SD. Is there something you do to get this dictionary to become unloaded first?
I never had a delay long enough with “system events” to even try to click safari before the dictionary was done. The dictionary appears in less then a second. It doesn’t matter if I quite and restart SD or clear the dictionary cache.
I tried the same things you described except I used the slowest loading application dictionary I had and I was easily able to click safari in the middle which stopped the current dictionary load, and started loading the Safari dictionary. It finished without any problems.
But I do wonder why you ever have time to start to load the “system events” dictionary. That difference might be important. The only thing I can think of is the “system events” app wasn’t at the correct path. El Capitan and up won’t let you move that but older systems will.
I just don’t know enough about how the dictionaries are handled internally by SD to come up with a better test or track it down. I suspect they might get loaded into memory and the dictionary cache is only there if there is a problem with loading an app dictionary. But that would still make the internal handling of dictionaries a big black box.
The issue is not the dictionary window, it’s the explorer window for System Events.
The dictionary loads just fine. When I click on the explorer window, if there is a delay populating all the information that’s when I get the crash if I click on the safari icon.
The explorer window’s information is not cached by SD, but loaded fresh each time. It seems to me that if the System Events has run recently the information populates the fields without delay. But if system events hasn’t been running there is some delay in populating the explorer fields and that’s when it’s vulnerable to a crash.
Just tried it again this morning on El Capitan and couldn’t reproduce. There was a very brief pause before the fields started getting populated. I clicked the safari icon and no crash. The pause was so brief that I didn’t click the Safari Icon before the information started flowing in. In previous crashes, all the fields said “waiting” when I clicked the Safari icon.
I let the mac sit for about half an hour after the previous attempt. In doc preferences I turned hiding off. I opened the System Events dictionary. (Didn’t have to click the explorer button, since it remembered the state. I got the dialog asking if I wanted to launch System Events. I positioned the window so the Launch button on the dialog was near the Safari icon in the dock. I clicked launch then immediately clicked the safari icon.
I was able to reproduce Ed’s crash on El Capitan 10.11.6. The first time I tried to reproduce it didn’t work but the second time it worked. The Apple and SD crash reports are included in this post. Nothing showed up in console.
As soon as I clicked the mouse when the mouse pointer was over Safari to select it in the explorer SD crashed. They seemed to have happened at the same time.
I added some steps to what Ed did to make it crash more reliably. I slowed down the explorer reload time after I quit “System Events.” I did this by launching the “Activity Monitor” and selecting “System Events” and clicking the icon with dark circle that has a white X inside it. (The image shown is top left of window in “Activity Monitor”)
This brings up the sheet dialog shown in the second image
I clicked “Quit” and a second or 2 later “System Events” disappears from the “Activity Monitor” list. Then I quit SD. I relaunched SD got the explorer window up. I clicked “System Events” in the far left column of explorer window and a dialog came up asking if I wanted to launch “System Events.”
Then I moved the mouse so it was over Safari in in the far left column of explorer window. Then I pressed the return key to select “Launch” button and right after that I clicked Safari to select it for the explorer window and SD crashed.
Thank you for the additional information. Unfortunately, try as I might on 10.11, I cannot make this crash happen. Unfortunately the crash reports your provided don’t point to a useful crash site.
I think I’ll release 6.0.3 as it fixes some other serious issues and regressions and then we can try and sort this out for 6.0.4.
It does require being really fast to get it too crash. The only way I could do it was to quit system events first. It has to be fast between clicking the mouse and hitting the return key. It is something a person can run into but I don’t think a huge number of people would run into it. There Macs would have to be running really slowly. The time gap seems like an important part. I would guess Ed’s mac runs a bit slower then most. But there’s no point in holding up fixes for thing that can be fixed.
Perhaps I can find another way to get at the problem. The key is to interrupt system events loading before it really gets started or else it doesn’t crash. Perhaps I can cause the same problem to occur with another app that would do something more informative. I’ll think about it.
If you want to put some special stuff in a test version of SD that prints things out to the console I can try it out.
I wouldn’t lose any sleep over this one. It seems to have been around a while, but even if you know how to cause it, it’s pretty tricky.
Is there any kind of crash reporting information that would be more helpful? I always figured in this kind of crash SD’s crash report would give you everything you need.
