Bytecode instruction number is typically related to position within the current function (where a function might be an actual function, or the top-level execution context for a given .ck file). They're not necessarily linearly related to line numbers or position in current function. In fact they are not even necessarily monotonically increasing in that respect, but in unoptimized bytecode (e.g., pretty much any bytecode ChucK generates) they probably are. Anecdotally, I was chasing down some annoying ChucK bugs a few weeks ago, and I just couldn't figure out where it was crashing after several solid hours of debugging. Desperate, I hacked in a quick/ dirty mapping of VM instruction -> .ck line number, and I figured out the bug in like 5 seconds. I think if this functionality was applied to the main ChucK branch, it could pin these random ChucK exceptions to specific line numbers, and also put ChucK on the path towards having its own debugger. spencer On May 7, 2009, at 7:33 PM, Tom Lieber wrote:
2009/5/7 Kassen
: These "bytcode instructions" are those linked more or less linearly to the file? What I mean is could one home in on the bug by intentionally having a array go out of bounds, then checking whether this results in a higher or a lower number?
Yeah, that seems likely. But I'm completely unfamiliar with ChucK's compiler, and no time to play with it tonight, unfortunately.
Another solution would of course be to look more closely before copy-pasting a entire loop and verifying whether all of the variables still make sense in the new scope... *cough*
:D
-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users