Re: Core dump in 21.4 building cc-align.el

vin> Using dmalloc and repeatedly calling dmalloc_verify(0) in vin> gdb, I was able to isolate the failure somewhat. The specpdl vin> gets overwritten in the function execute_optimized_program() vin> on the 4th time through this code: Oh, bravo! Good work! vin> line 480: ------------------------------------------------------------------------ if (!OPAQUEP (f->instructions)) /* Lazily munge the instructions into a more efficient form */ optimize_compiled_function (fun); /* optimize_compiled_function() guaranteed that f->specpdl_depth is the required space on the specbinding stack for binding the args and local variables of fun. So just reserve it once. */ SPECPDL_RESERVE (f->specpdl_depth); ------------------------------------------------------------------------ vin> 1. In this case, optimize_compiled_function() is not vin> called, so does anything guarantee that "f->specpdl_depth is vin> the required space on the specbinding stack for binding the vin> args and local variables of fun"? Yes, in the sense that the only way that f->instructions should be OPAQUEP is if o_c_f was called earlier on the byte code. Otherwise it should be STRINGP (ie, bytecode). Now I'm out of knowledge. Do you know what function is currently being compiled? It's probably somewhere in the stack trace (using debug_print from .gdbinit), but I don't know if that really matters. Also, you should be able to debug_print the forms referenced in frames #14 and #15 to figure out what Lisp is being executed. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.