On Dec 4, 2006, at 2:19 PM, Scott Hochberg wrote: > Thanks, Brian, > > Results are the same whether I boot from Classic, run it on a > "Classic-only" system, or check the Classic box on the get-info > window. > > Unfortunately, this is an erratic result - I had customer reports > of this behavior that I never could duplicate until I upgraded my > OS X to 10.4.8, upgraded to the new FB, and re-installed OS 9 > (necessary after upgrading my OS X for some reason). Prior to that, > it did not fail on my machine. Also, there are conditions I can > create where it will not fail even in this config, but they are > fairly random, so the whole thing points to some sort of memory > overwrite or other strangeness. I doubt the code posted (by you or me) is the genesis of the problem. There is an issue somewhere else and this is where it manifests. If memory overwrite issues are suspected, it might be productive to turn on the "Bounds error checking" (in preferences - advanced tab) for arrays. That doesn't cover all overwrite issues but it could be a start. Also, the FB debugger can be used to find the failing line of code and investigate variable contents. Another thought (and this might get you close fast) : turn on "include debugger labels - OS X traceback" on the Debug tab of preferences ( I typically quit FB at this point to make sure this setting is saved and immediately restart FB editor) This will provide labels from your source code (FN names and offsets) in the crashreporter log. Crashreporter logs can be found at : /Users/ YourUserID/Library/Logs/CrashReporter/ . Unless crashreporter is turned off (it is on by default) a crash log will appear when the FB applications crashes. HTH----Brian S.