latin-unity and jka-compr possibly fingered in bytecode lossage [was: Re: [Bug: 21.5-b15] Gnus crash]

Jerry> But since ERROR_CHECK_BYTE_CODE is defined for beta Jerry> versions, wouldn't the check at the top of the while loop Jerry> in execute_optimized_program catch that kind of problem? Jerry> Apparently not, but I don't understand why. sjt> That depends on whether any of the bytecodes do anything else sjt> with the stack. If there are any data manipulations that are sjt> byte-interpreter-stack-relative.... OK, I now have a reproducible case where bytecode execution is broken in 21.4.12. Basically if I byte-compile-and-load-file lisp/about.el, and set breakpoints at Fload_internal, then Fbyte_code, I see a very badly mangled call to Fbyte_code, with both the constants argument and the stack_depth argument trashed. Unfortuntely, it seems dependent on my environment. Turning off latin-unity (latin-unity-uninstall) seems to help, but doing xemacs -no-autoloads M-x load-library RET latin-unity RET M-x load-library RET bytecomp RET M-x byte-compile-and-load-file RET lisp/about.el RET does not produce the error, so this is going to take more effort to localize. I also have jka-compr loaded, but gotta run to a meeting and probably won't get back to this today, so I'll send this incomplete report now. -- 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.