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

Vin> Last April I reported a problem building cc-align.el using a non-Mule Vin> 21.4 on my Linux box; see Vin> http://list-archive.xemacs.org/xemacs-beta/200204/msg00506.html ... Vin> If I go back to funcall_compiled_function(), which calls Vin> execute_optimized_program(), I see: Vin> line 480: Vin> if (!OPAQUEP (f->instructions)) Vin> /* Lazily munge the instructions into a more efficient form */ Vin> optimize_compiled_function (fun); Vin> /* optimize_compiled_function() guaranteed that f->specpdl_depth is Vin> the required space on the specbinding stack for binding the args Vin> and local variables of fun. So just reserve it once. */ Vin> SPECPDL_RESERVE (f->specpdl_depth); Vin> In this case, f->specpdl_depth is 5, and if I increase it to 6 Vin> before calling SPECPDL_RESERVE, no crash occurs, because the size of Vin> specpdl is increased before calling execute_optimized_program(). Vin> 2 questions: Vin> 1. In this case, optimize_compiled_function() is not called, so does Vin> anything guarantee that "f->specpdl_depth is the required space Vin> on the specbinding stack for binding the args and local variables Vin> of fun"? Vin> 2. Did the bytecompiler just make a mistake in calculating the Vin> specpdl depth required for the specified function? I wrote all of the code in question. optimize_byte_code thinks it can count the required specpdl depth by counting the varbind opcodes in the bytecode. This assumption might be incorrect. It is conceivable that illegal or just plain weird bytecode might invalidate the assumption. Does the specpdl_depth calculated by optimize_byte_code() match the stack depth calculated by the byte compiler? I don't remember the details, but it seems the byte compiler does all the work to compute the stack depth, but bytecode.c ignores it and recomputes it from scratch, to avoid crashes due to bad bytecode. Yes, it would be an optimization if the stack depth were no longer stored in bytecode, but hard to make backward-compatible. Vin> Can anyone help here? I'm slightly out of my depth in messing with Vin> the bytecode interpreter, but I'm happy to continue investigating if Vin> anyone can give me a gentle nudge in the right direction. Vin> Let me know if there are more details I need to provide. Vin, you've been very nice to me lately. Give me access to your machine and I'll try to debug it. Martin