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.