I have a stay-open app that runs for only a few minutes then crashes with a SIGSEGV/Segmentation fault (11).
How do I isolate the offending code, navigate the traceback dump or debug this exception?
I saved the dumps so can supply if needed.
I have a stay-open app that runs for only a few minutes then crashes with a SIGSEGV/Segmentation fault (11).
How do I isolate the offending code, navigate the traceback dump or debug this exception?
I saved the dumps so can supply if needed.
That sort of crash is very low level, so chances are you won’t find much useful. Your best bet is to add code to your script that writes to a log file regularly, and use that to narrow down the offending code. Tedious, but usually effective.
I used to be quite skilled at interpreting trackbacks and stack dumps at an instruction set level. But understand your point and already implemented some message logging.
I suspect a nested repeat loop is probably causing the exception, but nevertheless that seems a bug in AppleScript itself or exceeding some memory region, limit or quota which would be surprising. Stay tuned.
To clarify, the crash would mostly appear in the form of one of those giant traceback/stack dumps with “Report will be sent to Apple” and the choices of OK or Reopen the offending app. I once filled out the comment section asking Apple to open a case and contact me for further information, which of course was ignored.
But also intermittently the app would instead trigger an “internal table overflow -2707” error, for which I would need to Force Quit the app.
I suspected a couple of sections of code, but the message logging suggestion greatly aided my isolation of the specific problem areas.
Code review prompted me to abandon several nested loops to process at times dozens of records in an SQL database (rows, columns and cells in Numbers doc) and, never runaway, but apparently problematic nevertheless. Made me explore and implement more creative and complex SQL queries, which eliminated the loops and greatly optimized the logic in these sections. So no more loops, and quite certain no more crashes.
Yes the app uses an SQL database, a Numbers spreadsheet, and contains several handlers called by a separate control app. Glad to share code but it’s almost 1000 lines and probably hard to follow without explanations and full context.
If you are getting these types of errors then your script is too long. We suggest a rule of thumb that any AppleScript source file should be no longer than 2000 lines of code. We have a post on this topic:
Great article and quite enlightening. I tightened my script down to 814 lines and no nested repeat loops so seems fine now.