On Sun, 27 Apr 2003, Steve Youngs wrote: While I can get XEmacs to build and compile, I get the following error for compilations that contain the -O3 flag for gcc and do not have --debug configured in. Further, I have discovered that if I replace the most recent version of subr.el with one from the CVS directly before it was changed, this error does not occur. There appears to be some pesky error related to low-memory access (running instructions at address 0x00000004 so far as I can see) that is somehow triggered by the changes to (split-string) I will add that some of the Mule tests fail and appear to be suffering from byte alignment problems. But the test aborts under make check and reports a 100% success rate. Here is the C Stack Trace from gdb running the command ./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el \ -f batch-update-elc-2 /usr/local/sbin/xemacs/src/../lisp #0 0x000c0264 in assq_no_quit (key=9436000, alist=13683384) at fns.c:1504 #1 0x001ba2a4 in kill_specifier_buffer_locals (buffer=9436000) at specifier.c:196 #2 0x00016a94 in Fkill_all_local_variables () at buffer.c:1698 #3 0x00063148 in Ffuncall (nargs=1, args=0xbfffe5f4) at eval.c:3842 #4 0x0001b7dc in execute_optimized_program (program=0xb56c60 "[BYTE CODE THAT WON'T PASTE]", stack_depth=3, constants_data=0xe7a518) at bytecode.c:609 #5 0x0006b69c in funcall_compiled_function (fun=15390460, nargs=0, args=0xbfffe8d8) at eval.c:3449 #6 0x000635b0 in Ffuncall (nargs=1, args=0xbfffe8d4) at eval.c:3881 #7 0x0001b7dc in execute_optimized_program (program=0x915b30 "[BYTE CODE THAT WON'T PASTE]", stack_depth=4, constants_data=0xe72e00) at bytecode.c:609 #8 0x0006b69c in funcall_compiled_function (fun=15373124, nargs=0, args=0xbfffebc8) at eval.c:3449 #9 0x000635b0 in Ffuncall (nargs=1, args=0xbfffebc4) at eval.c:3881 #10 0x0001b7dc in execute_optimized_program (program=0x9117e0 "[BYTE CODE THAT WON'T PASTE]", stack_depth=7, constants_data=0xe73638) at bytecode.c:609 #11 0x0006b69c in funcall_compiled_function (fun=15374796, nargs=0, args=0xbfffedc0) at eval.c:3449 #12 0x000628b8 in Feval (form=14576168) at eval.c:3660 #13 0x0005e280 in condition_case_1 (handlers=13810008, bfun=0x61a44 <Feval>, barg=14576168, hfun=0x2cf10 <cmd_error>, harg=13812144) at eval.c:1917 #14 0x0002d03c in top_level_1 (dummy=13812144) at cmdloop.c:214 #15 0x0005db60 in internal_catch (tag=13571952, func=0x2cfc4 <top_level_1>, arg=13812144, threw=0x0, thrown_tag=0x0) at eval.c:1527 #16 0x0002d1f4 in initial_command_loop (load_me=13812144) at cmdloop.c:280 #17 0x00057df8 in xemacs_21_5_b12_powerpc_apple_darwin6_5 (argc=9, argv=0xbffffbc8, envp=0xbffffbf0, restart=0) at emacs.c:2403 #18 0x00059088 in main (argc=9, argv=0xbffffbc8, envp=0xbffffbf0) at emacs.c:2833 #19 0x0000282c in _start (argc=9, argv=0xbffffbc8, envp=0xbffffbf0) at /SourceCache/Csu/Csu-45/crt.c:267 #20 0x000026ac in start () Here is the output from the OS X crash log: Date/Time: 2003-04-26 11:57:27 -0400 OS Version: 10.2.5 (Build 6L29) Host: grendal.frinabulax.org Command: xemacs PID: 9112 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000004 Thread 0 Crashed: #0 0x000c0264 in assq_no_quit (fns.c:1504) #1 0x001ba2a4 in kill_specifier_buffer_locals (specifier.c:196) #2 0x00016a94 in Fkill_all_local_variables (buffer.c:1702) #3 0x00063148 in Ffuncall (eval.c:3842) #4 0x0001b7dc in execute_optimized_program (bytecode.c:609) #5 0x0006b69c in funcall_compiled_function (eval.c:3449) #6 0x000635b0 in Ffuncall (eval.c:3881) #7 0x0001b7dc in execute_optimized_program (bytecode.c:609) #8 0x0006b69c in funcall_compiled_function (eval.c:3449) #9 0x000635b0 in Ffuncall (eval.c:3881) #10 0x0001b7dc in execute_optimized_program (bytecode.c:609) #11 0x0006b69c in funcall_compiled_function (eval.c:3449) #12 0x000628b8 in Feval (eval.c:3660) #13 0x0005e280 in condition_case_1 (eval.c:1917) #14 0x0002d03c in top_level_1 (cmdloop.c:214) #15 0x0005db60 in internal_catch (eval.c:1527) #16 0x0002d1f4 in initial_command_loop (cmdloop.c:285) #17 0x00057df8 in sort_args (emacs.c:2512) #18 0x00059088 in main (emacs.c:2836) #19 0x0000282c in _start (crt.c:267) #20 0x000026ac in start PPC Thread State: srr0: 0x000c0264 srr1: 0x0200f030 vrsave: 0x00000000 xer: 0x20000000 lr: 0x001ba2a4 ctr: 0x001c45bc mq: 0x00000000 r0: 0x00000000 r1: 0xbfffe2f0 r2: 0x00000000 r3: 0x00940b60 r4: 0x00d4dab8 r5: 0xbfffe254 r6: 0x00000000 r7: 0xbfffe25c r8: 0xbfffdfd4 r9: 0x00000000 r10: 0x000c0224 r11: 0x00d4dab8 r12: 0x001c45bc r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffffafc r27: 0x00000028 r28: 0x00000009 r29: 0xbffffb28 r30: 0xbfffe2f0 r31: 0x001ba25c I have written a shell script that deletes all source from src/, lisp/, lisp/mule/, and lisp/term/ before compiling and have turned -O3 off. Either action alone seems to fix the problem intermittently. I have compiled with various configuration options on or off. Setting --error-checking=all along with the erasure seems to work also. But also doing a real clean then rm lisp/*.elc will work sometimes, but then not others. The full erasure with not optimization has so far worked the three times I tried it. This reminds me of bugs I used to see in the early 1980s that my m68K machine would catch but that Intel-based machines would not when code would reference low memory (which on the Atari was off limits). The Intel code would compile and run, but eventually crash intermittently while the code would always fail on the Atari. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky Kill UGLY Corporate Radio Freedom does not mean you can do anything you want. It means you can *choose* your responsibility. -Frank Zappa