Re: crunchy crashy errors
Re: crunchy crashy errors
- Subject: Re: crunchy crashy errors
- From: Steven Angier <email@hidden>
- Date: Thu, 17 Jan 2002 09:09:27 +1100
- Organization: Macscript.com
has wrote:
>
I've got a fairly large project (a script server containing approx 8 loaded
>
libraries) that's sometimes causing my system (8.6) to crash. Mostly it
>
runs fine and does exactly what it should when I call it, but sometimes
>
when I call it, and for no obvious reason I can see, it'll cause my system
>
to freeze up, or else fall over, and I have to hard-restart.
You should install MacsBug and spit out a few stdLogs. This may shed some light onto the
nature of the problem (i.e. your script, an OSAX, AppleScript in general, or something
else).
>
I'm unsure of the cause at this point - the most likely culprits I can
>
think of are that it's running as a stay open server, it's chucking around
>
some fairly large objects and data (though the server's got plenty RAM
>
allocated now), and it's using "run script" to compile some pretty meaty
>
code on the fly.
>
>
A couple times I got system error that said something about a "CHK error",
>
right before I had to force restart the thing. Anyone know what that might
>
be about?
Don't know about "CHK error", but I would suspect the "growing handle" or some more
traditional memory leak, especially if your script server app is very busy or has been
running for a long period. You might try using MemMapper or (better) ZoneRanger (part of
Code Warrior IDE) to watch for this.
A few causes of memory leaks in AS (don't know if/how these affected 8.6):
* Growing handles -- slow but deadly. Basically, the memory allocated when creating an
AppleScript list is not always cleaned up properly after the list is destroyed. Every list
created in your script contributes to this problem -- including setting TIDs to a list
(e.g. {""}). This problem is insidious in that it doesn't simply claim more available
memory like a traditional "leak", rather the offending handle grows to run over whatever is
adjacent in memory. You'll have to use something like ZoneRanger to pick this problem.
* Internal coercion errors -- trying to use AppleScripts implicit date coercion on an
un-coercible value will obviously generate an error (e.g. date "xyz" -- rare, I know); the
problem is that the chunk of memory where the error record is stored is never released.
This may or may not be the case for other coercion errors.
* Undeclared local variables -- I have found in the past that local variables which are
not explicitly declared as local are not always cleaned up when returning to the calling
function. This is difficult to watch for in real time and it may have been fixed somewhere
along the way. To be safe, I always declare variables local to a function as local.
Good luck and let us know what you find out.
Steven Angier
Macscript.com