And here's another patch that fixes an off-by-one error in the bind-rest instruction. This solves the problems I was having in my earlier email about an abort in the VM.
Best, Noah On Sun, Apr 21, 2013 at 11:23 AM, Noah Lavine <noah.b.lav...@gmail.com>wrote: > Hello, > > Please don't worry about the last part of that message. I realized I can > test the nargs value by (ab)using the assert-nargs-ee instruction. > > On a related note, there's a certain piece of code in vm.c that is not > robust in the face of a corrupt nargs. Specifically, if you call > vm_error_wrong_num_args (vm.c:518 in wip-rtl) with nargs=-1, guile will > segfault. We could fix this, but I'm inclined to leave it as it is, because > this can only happen if nargs is corrupted by some earlier call, and I > think the right approach is to test the VM enough that nargs doesn't get > corrupted. Does that sound reasonable? If not, it should be simple to > insert some check there the nargs is big enough not to corrupt anything. > > Noah > > > On Sat, Apr 20, 2013 at 7:30 PM, Noah Lavine <noah.b.lav...@gmail.com>wrote: > >> Hello, >> >> I've attached three patches for wip-rtl. The first is somewhat different >> than the other two: it fixes an error that occurred when moving the linker >> to its own file. (system vm rtl) and (system vm linker) both contain a >> function called link-string-table, and (system vm rtl) was calling the >> wrong one, which made rtl.test fail. I solved this with an @-reference. >> >> The second two provide better VM errors when box-ref and box-set! are >> called on something that is not a variable. In particular, they throw an >> exception instead of aborting. This could occur in user code, if the user >> wants to hand-write RTL code, but it's also very useful in trying a new >> compiler implementation. The first patch handles box-ref, and the second >> handles box-set!. Also note that I had to add a new type of exception to >> (test-suite lib) to catch these errors. >> >> Lastly, I'd like to ask for ideas on how to test for errors in VM >> instructions that don't cause immediate problems, but do put the VM in an >> inconsistent state. I know of a collection of these errors, and while I >> could fix them, I'd rather fix them and add a test for them. I can think of >> two possibilities off the top of my head: 1) add Scheme accessors for VM >> state (I don't think mutators are necessary for now) or 2) write the tests >> in C instead of Scheme. >> >> I'd prefer option 1, mostly because I think that making the VM state more >> explicit is a good direction to go in anyway - eventually it would be great >> if the debugger could print the contents of registers, and that would >> require VM introspection anyway, so I think starting now is good. >> >> What do other people think of the patches and the ideas? >> >> Best, >> Noah >> > >
0001-Bugfix-in-vm-engine.c.patch
Description: Binary data
