From e5a1211e3b7df6a04de134b60d2dc5cfca3490e5 Mon Sep 17 00:00:00 2001 From: Kaz Kylheku Date: Tue, 10 Apr 2018 20:49:29 -0700 Subject: load: fix vm gc issue. This issue manifested itself as a segfault on Mac OS while compiling a library file using the compiled implementation (hash.tl -> hash.tlo2). The problem is premature reclamation of a virtual machine description. While the asm.tlo module is loaded, suddenly a function table goes corrupt. When we execute machine using vm_execute_toplevel, the vm's stack doesn't actually contain a reference to the description object anywhere. It's passed in as a parameter, and right away converted to the (struct vm_desc *) handle which is planted in the struct vm representing the running instance, which lives on the stack. That pointer isn't a reference traversed by the garbage collector. If the original Lisp object is optimized away and overwritten both in vm_execute_toplevel and in that function's caller, then it can be reclaimed even as it executes. * parser.c (read_file_common): Add a gc_hint(desc) after the vm_execute_toplevel so that the compiler thinks the value of the variable is still needed after the call. That keeps it around on the stack or in a register so that the garbage collector can see it as a root pointer. --- parser.c | 1 + 1 file changed, 1 insertion(+) (limited to 'parser.c') diff --git a/parser.c b/parser.c index 237860c8..5d310b5b 100644 --- a/parser.c +++ b/parser.c @@ -641,6 +641,7 @@ static val read_file_common(val stream, val error_stream, val compiled) val funvec = car(item); val desc = vm_make_desc(nlevels, nregs, bytecode, datavec, funvec); (void) vm_execute_toplevel(desc); + gc_hint(desc); } } else { (void) eval_intrinsic(form, nil); -- cgit v1.2.3