Kas: I've gotten a little mileage from launching ChucK under gdb: % gdb chuck then running it * r ...then when it bombs out, type "bt" for backtrace. Sometimes you can guess what's gone on by looking at the names of the functions on the stack. I've not taken the time to compile the system with a -g flag, which would allow me to see the actual source code where it bombed. (But note: the line number where it bombed will be in the ChucK code, not in your .ck file.) - Rob On 7 May 2009, at 18:31, Tom Lieber wrote:

2009/5/7 Kassen :

...

Let's have a look at this;

ArrayOutOfBounds: in shred[id=2:tr8or.ck], PC=[3565], index=[4]

Ok, so it's a array that gets defined in my main shred and it's one that's 4 or less elements in size. That narrows it down considerably but we're not there yet. Now, I have the feeling that ChucK is trying to tell me something with the "PC=[3565]" but that bit is quite useless to me as I have no idea what it means.

Questions; What does the PC bit mean? How is it useful? Can we consider ways of making it more useful?

I *think* it's "program counter," the number of the bytecode instruction where the exception occurred. A line number would be nicer, huh? :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

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/

Spencer; 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).

Thanks for the explanation, quite interesting.

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.

I would think this would be very worthwhile. Array out of bound errors are one of the most common issues for me (I'm a big fan of arrays and end up using them a lot) and they are one of the hardest to trace. I think this could be a big time saver. I expect that a ChucK debugger (in general) would help in learning about ChucK as well. These days I can usually tell but I remember that in the past I was often quite insecure about whether a issue was one of my own oopses or a ChucK-bug. It's pure speculation but I suspect a ChucK debugger might help in learning to write ChucK code as well as help with the debugging of ChucK itself because of this but that's purely based on my own experiences so far from objective. Yours, Kas.