Here’s a sample of ScriptDebugger taken when it was in an unstable state.
Basically I was pounding away at it debugging a script that works with lots of data.
I noticed this morning it started to hang (spinning rainbow disc).
I left it up and when I got home it was in the same unstable state.
When I switched to debugging mode it hung and became unresponsive. (that’s when I took the sample) I tried that trick where you pull down the Force quit menu, select the app and click force quit, and that cleared the hang. I quit, relaunched and it seems fine.
Unfortunately, the Sample report does not point to an obvious cause for the hang. It appears the code is laying out the text of the script for display, but nothing out of the ordinary seems to be happening.
Should this happen again, please grab another sample report and we’ll see if more information becomes available.
Thinking more about this, there is one remote possibility: a damaged or disabled font. Please make sure that all the fonts you are using in your AppleScript settings are enabled and in good order. Given that your problem was corrected by a quite and reboot, it may be an in-memory corruption and is always difficult to trace. If you were doing ASObjC stuff, then anything is possible.
The use of a library or not has no impact on ASObjCs stability. ASObjC allows you to generate calls that can potentially corrupt memory, and so must be used with great care. How that code is deployed (libraries, etc.) has no impact on this.
As an aside, and I think we’ve mentioned this elsewhere on the beta forum, if ever Script Debugger displays a Cocoa Exception dialog (the one with the Crash or Continue buttons), ONLY use Continue as a means allowing Script Debugger to continue running long enough to save your work. Once one of these alerts appears, you must consider Script Debugger wounded and ready to crash at any moment.
For ASObjC, it is very easy to make ASObjC do dangerous things with memory. There isn’t anything SD can do to protect you from this as its all happening within AppleScript. Shane has done an amazing job of generating safe code for you through clippings and code completion - use it exclusively. The failure to include the right set of () or incorrect handling of certain parameter types can lead to disaster (eg. treating a scalar as an object reference).
ASObjC memory corruptions are the hardest to diagnose because the corruption may have happened long in the past and the damaged memory may be reused/recycled, leading to a crash/strange behaviour much later on. Also, unlike native AS values, ASObjC objects share the same memory pool as Script Debugger its self. A ASObjC memory corruption may cause problems within AS as one might expect, but could also lead to incorrect Script Debugger behaviour.
OK It’s entered that unstable state again. Here’s a sample.
Every time I try to do something (run a script; compile; switch into and out of debugging mode; save) it starts to hang. The hangs were brief at first and get progressively longer. The one I sampled was at least half a minute.
Another sample. This time I’d been working with some big scripts with lots of data in the morning, and left SD up all afternoon and early evening. When I got back, every time I saved or switched windows got a long hang.
Thank you for capturing all the simple reports. Unfortunately, there isn’t an obvious cause shown. I wonder if some sort of memory leak is happening somewhere which could lead to this. Given that the slowdowns happen after prolonged use, this might make sense.
Next time it happens, check Script Debugger’s memory usage with Activity Monitor. I cannot really give you a “normal” memory usage figure as it will depend on what your scripts are doing and the amount of data they process. Here, with my customer support usage of trying various little snippets of code, Script Debugger is using 40-50MB of memory and has been running for 6 days.
If it does turn out to be a memory leak, then the difficult task of identifying the cause begins. It could be something Script Debugger is doing, but it could also be AppleScript, ASObjC or something else.
Keep in mind that AppleScript uses something called a stop-and-copy garbage collection scheme. This means that when AppleScript runs out of memory for user data, it will allocate a new block of memory larger than the last and copy everything into it. Its not clear if the old memory block is ever released. This means that over time, AppleScript will use more and more memory.
Further to what Mark says, AppleScriptObjC memory management is very poor. In many cases this doesn’t matter, but if you’re doing stuff involving lots of large blobs of data, an occasional relaunch is a good idea.
OK, I’ll relaunches at the first sign of hangs which seems to work.
When I have time I’ll get memory usage and samples before it hangs, when it first starts to hang and when it becomes unusable.
The scripts are dealing with large lists and do have some ASObjC sprinkled in.
(They run fine as applets or in Script editor. I’ve been doing basically the same version of this script since 2005, and it takes 15 minutes to run. This new version less than 3 minutes, and I could probably shorten that if I were to rewrite it from scratch and use SQLLite to manage the data)