On Tue, 16 Jul 2002, art(a)brightlight.com wrote: Also, crashes doing ^x^e (eval-last-sexp) in 21.4.6 Note that the form is invalid - presumably you really didn't want to bind 3 to nil, eg: you want (let ((n 3)) n) -jeff

On 16 Jul 2002, james(a)xemacs.org wrote: Interesting. Yes, I was running on a solaris. I get the expected wrong type argument error in the minibuffer in the windows version. let is implemented in eval.c. Each var, if it isn't a symbol, must be a CONS, it is explictly checked in 'CHECK_CONS (var);' It is a little hard to follow the macros, but the implementation seems fine. Why would it break only on solaris? My (emacs-version) is "XEmacs 21.4 (patch 6) \"Common Lisp\" [Lucid] (sparc-sun-solaris2.8) of Mon Mar 4 2002 on capital" -jeff

Adrian Aichner <adrian(a)xemacs.org&gt; wrote: FWIW, I found a Sparc Solaris machine here that has an XEmacs 21.1.11 on it. It displays the same problem. Evaluating (let (3) t) is sufficient. Here is its installation info. That box has gcc 2.95.3 now, but there's no telling what version it was when this XEmacs was built. ------------------------------------------------------------------------ uname -a: SunOS [censored] 5.6 Generic_105181-14 sun4u sparc SUNW,Ultra-60 ../configure '--site-runtime-libraries=/usr/dt/lib /usr/openwin/lib' '--gung-ho' '--with-gnu-make' '--with-menubars=lucid' '--with-scrollbars=motif' '--with-pop' '--with-workshop' XEmacs 21.1.11 "Carlsbad Caverns" configured for `sparc-sun-solaris2.6'. Where should the build process find the source code? /tools/xemacs/distribution/xemacs-21.1.11 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -mcpu=supersparc -O2 Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Runtime library search path: /usr/dt/lib:/usr/openwin/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for DBM. Compiling in support for ncurses. Compiling in support for ToolTalk. Compiling in support for Sun WorkShop. Compiling in support for proper session-management. Using Lucid menubars. Using Motif scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using POP for mail access Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. ------------------------------------------------------------------------ I can't find a debugger I understand on this machine, unfortunately. All I can find is mdb, which is very cryptic to this gdb user. If nobody figures this out before tomorrow, I'll see if gcc 2.95.3 produces the same problem, and if so whether it is a compiler optimization bug (probably). -- Jerry James http://www.ittc.ku.edu/~james/

Jeff Mincy <jeff(a)delphioutpost.com&gt; wrote: It is definitely a compiler bug. With gcc 2.95.3, using "-mcpu=ultrasparc -O2" triggers the segfault. Using "-mcpu=ultrasparc -O" gives the correct behavior. I tried for awhile to track down which specific optimization is triggering the problem, but didn't find it. Somebody who cares enough to figure it out but has more patience than me doesn't need to bother trying any of these: -fno-force-mem, -fno-force-addr, -fno-strength-reduce, -fno-delayed-branch, -fno-schedule-insns, -fno-schedule-insns2. Regards, -- Jerry James http://www.ittc.ku.edu/~james/

Valdis.Kletnieks(a)vt.edu wrote: Okay, but we know that the same version of the compiler when used on another platform (x86 Linux) does *not* cause the same program behavior. This argues strongly for the problem being in the compiler back end (for the Sparc, in this case). Now, if we just knew that -O2 invoked the same set of optimizations on both platforms, I would say that with more certainty...:-) Just in case, here's the preprocessed version of the line that is crashing, reformatted to see it more easily. The crash is inside the if test somewhere. if (((((enum Lisp_Type) (((unsigned long)(var)) & ~(((1UL << ((4 * 8) - 2)) - 1UL) << 2))) == Lisp_Type_Record) && (((unsigned int)(((struct lrecord_header *) ((void *) (var)))->type)) == ((unsigned int)(lrecord_type_symbol))))) *value = Qnil; The crash happens when the CPU tries to read the contents of memory pointed to by a register that just happens to be holding the value 1. No matter what the value of var is here, that shouldn't happen. When it's a number, the first test should fail and shortcut the second one ... shouldn't it? -- Jerry James http://www.ittc.ku.edu/~james/

On Fri, 19 Jul 2002, stephen(a)xemacs.org wrote: Here, xemacs 21.1.11 which does not exhibit this bug was compiled with: -g -O3 -Wall -Wno-switch My xemacs 21.4.6 which does exhibit this bug was compiled with: -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wshadow -Wpointer-arith I can't be positive that gcc version was the same in both versions. But, there is a good chance that the offending switch is one of the ... -Winline -Wmissing-prototypes -Wsign-compare -Wshadow -Wpointer-arith Not I.... said the duck cares to look ... at the wetware? Eeewww. -jeff

I have a bit more info. Here is my broken out code. idx = 0; { LIST_LOOP_2 (var, varlist) { Lisp_Object *value = &temps[idx++]; EMACS_UINT sam = var.gu.type; // SAM if (SYMBOLP (var)) // SAM if(RECORDP(var, symbol)) // SAM if(RECORD_TYPEP (var, lrecord_type_symbol)) // SAM if(LRECORDP (var) && if(sam == Lisp_Type_Record) { if(((unsigned int)(XRECORD_LHEADER (var)->type)) == ((unsigned int)(lrecord_type_symbol))) *value = Qnil; else goto doit; } else { Lisp_Object tem; doit: I run XEmacs in gdb. After the crash: (gdb) print var $2 = {gu = {type = Lisp_Type_Int_Even, val = 1}, s = {bits = 1, val = 2}, u = { bits = 1, val = 2}, ui = 5, i = 5, v = 0x5, cv = 0x5} (gdb) print sam $3 = 1 Something is very not right here..... Cheers, Sean P.S. I am running the the Winder

Sean MacLennan writes: Interesting. The gu part of the union apparently has separate storage space. Could you "print sizeof(var)"?

Valdis.Kletnieks(a)vt.edu wrote: I get this: (gdb) print var $1 = {gu = {val = 0, type = Lisp_Type_Int_Even}, s = {val = 0, bits = 1}, u = { val = 0, bits = 1}, ui = 1, i = 1, v = 0x1, cv = 0x1} (gdb) print sizeof(var) $2 = 4 which looks normal. But it crashes anyway. Stict aliasing was turned off by default for 2.95.2: <URL:http://gcc.gnu.org/gcc-2.95/features.html>;. In any case, compiling with -fno-strict-aliasing produced identical binary code. This is interesting. Here is the preprocessed version of the current code: Lisp_Object *value = &temps[idx++]; if ((var.gu.type == Lisp_Type_Record && (unsigned int)(((struct lrecord_header *) ((void *)var.ui))->type) == (unsigned int)lrecord_type_symbol)) *value = Qnil; Given what GDB said about the value of var above, the if test definitely should have failed. Here is the preprocessed version with Sean's change: Lisp_Object *value = &temps[idx++]; volatile unsigned int sam = var.gu.type; if ((var.gu.type == Lisp_Type_Record && (unsigned int)(((struct lrecord_header *) ((void *)var.ui))->type) == (unsigned int)lrecord_type_symbol)) *value = Qnil; Now look what gcc did. The register allocation is slightly different, but don't let that confuse you. The assembly for the original is on the left. The assembly for Sean's version is on the right. The correspondence isn't perfect, but I tried to match up equivalent parts. .LL348: .LL348: .stabn 68,0,910,.LLM418-Flet .stabn 68,0,910,.LLM418-Flet .LLM418: .LLM418: .LLBB32: .LLBB32: .stabn 68,0,911,.LLM419-Flet .stabn 68,0,911,.LLM419-Flet .LLM419: .LLM419: andcc %l0, 3, %o0 and %l0, 3, %o0 .stabn 68,0,910,.LLM420-Flet .stabn 68,0,910,.LLM420-Flet .LLM420: .LLM420: add %l1, 4, %l1 add %l1, 4, %l1 .stabn 68,0,911,.LLM421-Flet .stabn 68,0,912,.LLM421-Flet .LLM421: .LLM421: ldub [%l0], %o1 mov %o0, %o1 .stabn 68,0,910,.LLM422-Flet .LLM422: add %l6, 1, %l6 .stabn 68,0,911,.LLM423-Flet .LLM423: st %o0, [%fp-36] .stabn 68,0,911,.LLM422-Flet .stabn 68,0,912,.LLM424-Flet .LLM422: .LLM424: cmp %o0, 0 bne,pt %icc, .LL351 bne,pt %icc, .LL382 cmp %o1, 0 add %l6, 1, %l6 ldub [%l0], %o0 cmp %o1, 4 cmp %o0, 4 bne,pt %icc, .LL382 bne,pt %icc, .LL351 cmp %o0, 0 cmp %o1, 0 .stabn 68,0,912,.LLM423-Flet .stabn 68,0,913,.LLM425-Flet .LLM423: .LLM425: ld [%l4+%lo(Qnil)], %o0 ld [%l4+%lo(Qnil)], %o0 ba,pt %xcc, .LL347 ba,pt %xcc, .LL347 st %o0, [%l1-4] st %o0, [%l1-4] Gazing into my crystal ball, I see that var is stored in %l0 in both cases. The first and, with 3, is to extract var.gu.type. I don't get the addition of 4 to %l1. But now look! The code on the left next tries to dereference %l0 (var), and read the byte it points to into %o1! It is trying to do the right hand side of the && expression *before* doing the left hand side, which is the next chunk of code. This is just wrong. I don't know why Sean's addition made gcc behave, but you'll see that the right hand side does it in the correct order. It next copies %o0 (var.gu.type) into %o1 for later use. Then it adds 1 to %l6 (idx). Then it stores %o0 into a stack slot (sam). Then it compares %o0 (var.gu.type) to 0 (Lisp_Type_Record). If they are unequal, it jumps right out of this section of code, like it is supposed to do. Otherwise, it does a useless comparison of %o1 (also var.gu.type) to 0 (Lisp_Type_Record) and ignores the result. Only then does it dereference %l0 (var), unlike the left side. Anyway, it looks to me like the ldub instruction was inserted into the instruction stream way too early on the left side. It should have been right before LLM423. I really don't think the XEmacs code can be blamed for this. -- Jerry James http://www.ittc.ku.edu/~james/

Kyle Jones <kyle_jones(a)wonderworks.com&gt;, on Fri, 19 Jul 2002 at 11:29:59 -0700 you wrote: I already tried them individually: <URL:http://list-archive.xemacs.org/xemacs-beta/200207/msg00379.html>;. I just tried turning them both off at the same time, and still no joy. -- Jerry James http://www.ittc.ku.edu/~james/

I'm going to change the subject line to something more relevant. Sean MacLennan <seanm(a)seanm.ca&gt; wrote: [snip] [snip] I wondered about this myself while trying to chase down this problem. Here is the definition of RECORD_TYPEP (from lrecord.h): #define RECORD_TYPEP(x, ty) \ (LRECORDP (x) && (XRECORD_LHEADER (x)->type == (unsigned int) (ty))) Okay, I certainly want to be sure that x is an lrecord before pulling the type out of the header (in spite of what gcc is doing on the Sparc and the ARM, eh?). And since XRECORD_LHEADER(x)->type has type unsigned int, I can understand casting ty (which has type "enum lrecord_type" in every place that it is used) to unsigned int. The definition of LRECORDP is pretty understandable, and I can see why all the casts it uses are required. On the other hand, here is XRECORD_LHEADER, also from lrecord.h: #define XRECORD_LHEADER(a) ((struct lrecord_header *) XPNTR (a)) Okay, that cast is clear enough. But then we get to XPNTR. It is declared in lisp.h: #define XPNTR(x) ((void *) XPNTRVAL(x)) and XPNTRVAL is declared in lisp-disunion.h: #define XPNTRVAL(x) (x) /* This depends on Lisp_Type_Record == 0 */ and lisp-union.h: #define XPNTRVAL(x) ((x).ui) This is where it starts to get funny. Grepping on the sources again shows that, with one exception, everywhere that XPNTR is used, its type is immediately cast to some kind of pointer. The one exception is in alloc.c (in alloc_automanaged_lcrecord), where the value of XPNTR is returned from a function declared as returning "void *", so any type of pointer can be returned. So the cast to (void *) in XPNTR is superfluous. Also, in the lisp-union case, we are taking x *as an unsigned int*, not as a pointer (that would be x.v)! And finally, XPNTRVAL is only used in the definition of XPNTR. So wouldn't it make more sense to require users of XPNTR to give the type of pointer wanted, and define them like this? #define XPNTR(ty,x) ((ty *) XPNTRVAL(x)) lisp-disunion.h: #define XPNTRVAL(x) (x) lisp-union.h: #define XPNTRVAL(x) ((x).v) The only cases where this would not work is the uses of XPNTR in print_symbol_value_magic (in symbols.c) and internal_object_printer (print.c). But there, the format strings should be using %p instead of %lx, in which case the casts to (long) and (unsigned long) would be unnecessary anyway. The (unsigned long) cast in internal_object_printer should be (long), anyway, to match the format string. I just tried that on a Sparc machine. It compiles without complaint but (*sigh*) doesn't solve the crash we've been discussing to death. -- Jerry "C-u 3 M-x work-avoidance-mode" James http://www.ittc.ku.edu/~james/ "It's like an Alcatraz around my neck." -- Boston mayor Menino on the shortage of city parking spaces

Sean> [1] It takes about 1 hour to compile all of xemacs. So I Sean> have been cheating: Sean> edit lrecord.h or lisp-union.h or any important .h file Sean> touch *.c Sean> touch *.o Sean> rm eval.o Sean> make How about just `make eval.o'? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

On Sat, 20 Jul 2002, Martin Buchholz moaned: In many cases, GCC will notice things like (foo *) ((void *) bar) and elide the useless cast to `void *'. Not sure. It doesn't happen to me, with GCC 2.95.x, 3.0.x, 3.1.x, on Solaris or Linux SPARCs, with or without -mcpu=ultrasparc. I'm feeling all left out now. ;} -- `There's something satisfying about killing JWZ over and over again.' -- 1i, personal communication

On Mon, 22 Jul 2002, Martin Buchholz uttered the following: Quite so: but the compiler is permitted to *ignore* that cast to `void *' when it comes to determining what the expression is permitted to alias. (AIUI, of course; the parts of the Standard that define the parameters of aliasing in C are not very clear :( ) -- `There's something satisfying about killing JWZ over and over again.' -- 1i, personal communication

Kyle Jones writes: sizeof(var) = 4 /Sean

Nix <nix(a)esperi.demon.co.uk&gt; wrote: Dang. I'm going to have to rein in my altruistic impulses. This has gotten way more involved than I thought it would. Okay, so now I've recompiled without *any* -mcpu=xxx flags, which should give me the default v7 output. It still crashes in the same place. The instruction stream now looks like this: .LL339: .stabn 68,0,910,.LLM393-Flet .LLM393: .LLBB32: .stabn 68,0,911,.LLM394-Flet .LLM394: ldub [%l0], %o1 andcc %l0, 3, %o0 .stabn 68,0,910,.LLM395-Flet .LLM395: add %l1, 4, %l1 .stabn 68,0,911,.LLM396-Flet .LLM396: bne .LL342 add %l5, 1, %l5 cmp %o1, 4 bne .LL373 cmp %o0, 0 .stabn 68,0,912,.LLM397-Flet .LLM397: ld [%l4+%lo(Qnil)], %o0 b .LL338 st %o0, [%l1-4] That's even worse than it was in the -mcpu=ultrasparc case. Now the ldub has floated all the way to the top, before it even does the andcc to get the type! -- Jerry James http://www.ittc.ku.edu/~james/

Nix <nix(a)esperi.demon.co.uk&gt; wrote: I don't know. I've only got 2.95.3 on that box, and, sorry, at this point I'm not building gcc 3.1 on it. I've got other fish to fry for the next few days. It's about time for a random quote, isn't it? -- Jerry "M-x work-avoidance-mode" James http://www.ittc.ku.edu/~james/ "Taurus: The stars predict tomorrow you'll wake up, do a bunch of stuff and then go back to sleep." -- Weird Al Yankovic, "Your Horoscope for Today"

Art> Xeamcs 21.4.8 crashes while doing M-x eval-print-last-sexp Art> on a form in the *scratch* buffer. This is repeatable in Art> a fresh emacs. Art> To repeat: Art> 1. Enter the following form in the *scratch* buffer: Art> (let (n 3) (print n)) Hi Art, above lisp is incorrect, but this should never crash XEmacs! (let (n 3) tries to bind n to nil, which is OK, but it also tries to bind 3 to nil! In order to bind n to 3, you would have to write it this way: (let ((n 3)) (print n)) Please eval (Info-goto-node "(lispref)Local Variables") for details. (emacs-version) "XEmacs 21.5 (beta7) \"broccoflower\" [Lucid] (i586-pc-win32, Mule) of Sat Jul 06 2002 on D5DC120J" does not crash, instead I get this: Wrong type argument: consp, 3 # bind (standard-output stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error) # (unwind-protect ...) (let (n 3) (print n)) eval((let (n 3) (print n))) # bind (expr) eval-interactive((let (n 3) (print n))) # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) eval-last-sexp(t) # bind (standard-output) #<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 446892 nil>() call-interactively(eval-print-last-sexp) command-execute(eval-print-last-sexp t) # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) execute-extended-command(nil) # bind (command-debug-status) call-interactively(execute-extended-command) # (condition-case ... . error) # (catch top-level ...) Best regards, Adrian Art> 2. Place cursor after the final close-paren Art> 3. Type M-x eval-print-last-sexp Art> The output of M-x describe-distribution, the lisp backtrace, and Art> the C backtrace from the core file follow. Art> eval-print-last-sexp has not been modified from the standard distribution: Art> `eval-print-last-sexp' is an interactive compiled Lisp function Art> -- loaded from "/sandbox/mgleeson/xemacs-21.4.8/lisp/lisp-mode.elc" Art> (eval-print-last-sexp) Art> Documentation: Art> Evaluate sexp before point; print value into current buffer. Art> uname -a: SunOS dev26 5.6 Generic_105181-29 sun4u sparc Art> ./configure '--prefix=/home/mgleeson' '--site-prefixes=/home/mgleeson' '--with-dialogs=no' '--with-widgets=no' Art> XEmacs 21.4.8 "Honest Recruiter" configured for `sparc-sun-solaris2.6'. Art> Compilation / Installation: Art> Source code location: /sandbox/mgleeson/xemacs-21.4.8 Art> Installation prefix: /home/mgleeson Art> Additional prefixes: /home/mgleeson Art> Runtime library search path: /home/mgleeson/lib:/usr/dt/lib:/usr/openwin/lib:/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 Art> Operating system description file: `s/sol2.h' Art> Machine description file: `m/sparc.h' Art> Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wshadow -Wpointer-arith Art> Relocating allocator for buffers: yes Art> GNU version of malloc: yes Art> Window System: Art> Compiling in support for the X window system: Art> - X Windows headers location: /usr/dt/include /usr/openwin/include Art> - X Windows libraries location: /usr/dt/lib /usr/openwin/lib Art> - Handling WM_COMMAND properly. Art> Using Lucid menubars. Art> Using Lucid scrollbars. Art> TTY: Art> Images: Art> Compiling in support for GIF images (builtin). Art> Compiling in support for XPM images. Art> Compiling in support for PNG images. Art> Compiling in support for JPEG images. Art> Compiling in support for X-Face message headers. Art> Sound: Art> Compiling in support for sound (native). Art> Compiling in support for NAS (network audio system). Art> Databases: Art> Compiling in support for GNU DBM. Art> Internationalization: Art> Mail: Art> Compiling in support for "dot-locking" mail spool file locking method. Art> Other Features: Art> Inhibiting IPv6 canonicalization at startup. Art> Compiling in support for ToolTalk. Art> Compiling in support for dynamic shared object modules. Art> [art＠dev26 art]$ Art> Fatal error (11). Art> Your files have been auto-saved. Art> Use `M-x recover-session' to recover them. Art> If you have access to the PROBLEMS file that came with your Art> version of XEmacs, please check to see if your crash is described Art> there, as there may be a workaround available. Art> Otherwise, please report this bug by running the send-pr Art> script included with XEmacs, or selecting `Send Bug Report' Art> from the help menu. Art> As a last resort send ordinary email to `crashes(a)xemacs.org&#39;. Art> *MAKE SURE* to include the information in the command Art> M-x describe-installation. Art> If at all possible, *please* try to obtain a C stack backtrace; Art> it will help us immensely in determining what went wrong. Art> To do this, locate the core file that was produced as a result Art> of this crash (it's usually called `core' and is located in the Art> directory in which you started the editor, or maybe in your home Art> directory), and type Art> gdb /home/mgleeson/bin/xemacs core Art> then type `where' when the debugger prompt comes up. Art> (If you don't have GDB on your system, you might have DBX, Art> or XDB, or SDB. A similar procedure should work for all of Art> these. Ask your system administrator if you need more help.) Art> Lisp backtrace follows: Art> (let (n 3) (print n)) Art> eval((let (n 3) (print n))) Art> # bind (expr) Art> eval-interactive((let (n 3) (print n))) Art> # bind (standard-output opoint ignore-quotes eval-last-sexp-arg-internal) Art> eval-last-sexp(t) Art> # bind (standard-output) Art> #<compiled-function nil "...(13)" [standard-output terpri eval-last-sexp t] 2 984488 nil>() Art> call-interactively(eval-print-last-sexp) Art> command-execute(eval-print-last-sexp t) Art> # bind (_execute_command_keys_ _execute_command_name_ prefix-arg) Art> execute-extended-command(nil) Art> # bind (command-debug-status) Art> call-interactively(execute-extended-command) Art> # (condition-case ... . error) Art> # (catch top-level ...) Art> Current directory is /home/mgleeson/bin/ Art> GNU gdb 4.17 Art> Copyright 1998 Free Software Foundation, Inc. Art> GDB is free software, covered by the GNU General Public License, and you are Art> welcome to change it and/or distribute copies of it under certain conditions. Art> Type "show copying" to see the conditions. Art> There is absolutely no warranty for GDB. Type "show warranty" for details. Art> This GDB was configured as "sparc-sun-solaris2.6"... Art> (gdb) core /home/art/core Art> Core was generated by `/home/mgleeson/bin/xemacs'. Art> Program terminated with signal 11, Segmentation Fault. Art> Reading symbols from /home/mgleeson/lib/libaudio.so.1.4...done. Art> Reading symbols from /usr/dt/lib/libtt.so.2...done. Art> Reading symbols from /usr/openwin/lib/libXmu.so.4...done. Art> Reading symbols from /usr/openwin/lib/libXt.so.4...done. Art> Reading symbols from /usr/openwin/lib/libXext.so.0...done. Art> Reading symbols from /usr/openwin/lib/libX11.so.4...done. Art> Reading symbols from /usr/lib/libkstat.so.1...done. Art> Reading symbols from /usr/lib/libm.so.1...done. Art> Reading symbols from /usr/lib/libsocket.so.1...done. Art> Reading symbols from /usr/lib/libnsl.so.1...done. Art> Reading symbols from /usr/lib/libdl.so.1...done. Art> Reading symbols from /usr/lib/libc.so.1...done. Art> Reading symbols from /usr/openwin/lib/libSM.so.6...done. Art> Reading symbols from /usr/openwin/lib/libICE.so.6...done. Art> Reading symbols from /usr/lib/libmp.so.2...done. Art> Reading symbols from /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done. Art> #0 0xef38a5f0 in _kill () Art> (gdb) where Art> #0 0xef38a5f0 in _kill () Art> #1 0x7aaf0 in fatal_error_signal (sig=11) at emacs.c:539 Art> #2 <signal handler called> Art> #3 Flet (args=20745156) at eval.c:911 Art> #4 0x82e0c in Feval (form=20745120) at eval.c:3304 Art> #5 0x835d8 in Ffuncall (nargs=1, args=0xefffe30c) at eval.c:3528 Art> #6 0x585c8 in execute_optimized_program (program=0x146236e "\207map", Art> stack_depth=1, constants_data=0x3f0390) at bytecode.c:746 Art> #7 0x58220 in funcall_compiled_function (fun=2665460, nargs=1, Art> args=0xefffe4e4) at bytecode.c:515 Art> #8 0x837b8 in Ffuncall (nargs=1, args=0xefffe4e0) at eval.c:3563 Art> #9 0x585c8 in execute_optimized_program ( Art> program=0x1462462 "!+\207relsymlink-regexp", stack_depth=1, Art> constants_data=0x3f0310) at bytecode.c:746 Art> #10 0x58220 in funcall_compiled_function (fun=2665488, nargs=1, Art> args=0xefffe6c0) at bytecode.c:515 Art> #11 0x837b8 in Ffuncall (nargs=1, args=0xefffe6bc) at eval.c:3563 Art> #12 0x585c8 in execute_optimized_program (program=0x1414738 "\210Á )\207", Art> stack_depth=1, constants_data=0x3ef130) at bytecode.c:746 Art> #13 0x58220 in funcall_compiled_function (fun=2665432, nargs=0, Art> args=0xefffe8f0) at bytecode.c:515 Art> #14 0x837b8 in Ffuncall (nargs=0, args=0xefffe8ec) at eval.c:3563 Art> #15 0x86d44 in apply1 (fn=2665432, arg=2394116) at eval.c:4152 Art> #16 0x5c0f8 in Fcall_interactively (function=4213796, record_flag=2394140, Art> keys=2394116) at callint.c:397 Art> #17 0x82550 in Fcommand_execute (cmd=4213796, record_flag=2394140, Art> keys=2394116) at eval.c:2970 Art> #18 0x83604 in Ffuncall (nargs=-1, args=0xefffec04) at eval.c:3528 Art> #19 0x585c8 in execute_optimized_program ( Art> program=0x6eba51 "\210\013­8\b¬\023Ñ Ò a«\aÓ pa«\006Ô \210ª\004Õ \210Ö×!­\eØÙË\013A«\004Úª\002Û\nÜ\013!#\"\210Ö\016\036!\210ÝÙ!*\207Ï\fÐ\"\2075", Art> stack_depth=2, constants_data=0x308810) at bytecode.c:746 Art> #20 0x58220 in funcall_compiled_function (fun=3188540, nargs=1, Art> args=0xefffeddc) at bytecode.c:515 Art> #21 0x837b8 in Ffuncall (nargs=1, args=0xefffedd8) at eval.c:3563 Art> #22 0x5d40c in Fcall_interactively (function=3230156, record_flag=2394116, Art> keys=2394116) at callint.c:940 Art> #23 0x82550 in Fcommand_execute (cmd=3230156, record_flag=2394116, Art> keys=2394116) at eval.c:2970 Art> #24 0xaf30c in execute_command_event (command_builder=0x4dee80, event=15432728) Art> at event-stream.c:3915 Art> #25 0xaf950 in Fdispatch_event (event=20346884) at event-stream.c:4199 Art> #26 0x620e8 in Fcommand_loop_1 () at cmdloop.c:583 Art> #27 0x62350 in command_loop_1 (dummy=2394116) at cmdloop.c:494 Art> #28 0x7f7ec in condition_case_1 (handlers=2394212, Art> bfun=0x62334 <command_loop_1>, barg=2394116, hfun=0x623b0 <cmd_error>, Art> harg=2394116) at eval.c:1651 Art> #29 0x624c0 in command_loop_2 (dummy=2394116) at cmdloop.c:256 Art> #30 0x8760c in internal_catch (tag=2474156, func=0x62474 <command_loop_2>, Art> arg=2394116, threw=0x0) at eval.c:1317 Art> #31 0x61c94 in initial_command_loop (load_me=2394116) at cmdloop.c:305 Art> #32 0x7c43c in sort_args (argc=2184192, argv=0xeffff60c) at emacs.c:2353 Art> #33 0x7e070 in voodoo_free_hook (mem=0x1) at emacs.c:2782 Art> (gdb) -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Art Medlar writes: Another data point. Both of the above crash my 'Winder. XEmacs is version 21.4.8 The NetWinder is running a StrongARM processor on a Redhat 6ish Linux. gcc is version 2.95.1, compiled -O3 Cheers, Sean

Stephen J. Turnbull writes: Off. Here is the complete describe-installation: uname -a: Linux opus 2.2.16-sam1 #12 Fri Jul 14 22:33:17 EDT 2000 armv4l unknown ./configure '--package-path=/home/xemacs/packages:~/.xemacs' '--with-dialogs=no' '--with-widgets=no' XEmacs 21.4.8 "Honest Recruiter" configured for `armv4l-unknown-linux'. Compilation / Installation: Source code location: /home/xemacs/xemacs-21.4 Installation prefix: /usr/local Operating system description file: `s/linux.h' Machine description file: `m/arm.h' Compiler: gcc -g -O3 -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wshadow Relocating allocator for buffers: no GNU version of malloc: yes - Using Doug Lea's new malloc from the GNU C Library. Window System: Compiling in support for the X window system: - X Windows headers location: /usr/X11/include - X Windows libraries location: /usr/X11/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. TTY: Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Compiling in support for X-Face message headers. Sound: Compiling in support for sound (native). Databases: Compiling in support for Berkeley database. Compiling in support for LDAP. Compiling in support for PostgreSQL. - Using PostgreSQL header file: pgsql/libpq-fe.h Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for dynamic shared object modules. Cheers, Sean

Here at work on my Solaris box, (let (0)) ==> "Wrong type argument: consp, 0" I've included the contents of my Installation file. gcc is version 3.1. uname -a: SunOS denver 5.5.1 Generic_105428-01 sun4u sparc SUNW,Ultra-5_10 Solaris ../../../src/xemacs-21.4-sjt-2002-07-12/configure '--prefix=/u/shelton2/software/SunOS-5.5/xemacs-21.4-sjt-2002-07-12' '--with-gcc' '--site-includes=/u/shelton2/software/SunOS-5.5/include' '--site-libraries=/u/shelton2/software/SunOS-5.5/lib' '--infopath=/u/shelton2/software/info' '--with-mule=no' '--compiler=gcc' '--cflags=-O2 -pipe -ffast-math -fno-exceptions' '--with-dialogs=no' '--with-widgets=no' '--package-path=/u/shelton2/software/site-packages::/u/shelton2/software/xemacs-packages' '--debug=no' '--error-checking=none' XEmacs 21.4.9 "Informed Management (RC2)" configured for `sparc-sun-solaris2.5.1'. Compilation / Installation: Source code location: /u/shelton2/software/src/xemacs-21.4-sjt-2002-07-12 Installation prefix: /u/shelton2/software/SunOS-5.5/xemacs-21.4-sjt-2002-07-12 Additional header files: /u/shelton2/software/SunOS-5.5/include Additional libraries: /u/shelton2/software/SunOS-5.5/lib Runtime library search path: /u/shelton2/software/SunOS-5.5/lib:/usr/dt/lib:/usr/openwin/lib:/u/shelton2/software/SunOS-5.5/gcc-3.1/lib/gcc-lib/sparc-sun-solaris2.5.1/3.1/../../.. Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: gcc -O2 -pipe -ffast-math -fno-exceptions Relocating allocator for buffers: yes GNU version of malloc: yes Window System: Compiling in support for the X window system: - X Windows headers location: /usr/dt/include /usr/openwin/include - X Windows libraries location: /usr/dt/lib /usr/openwin/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Sound: Databases: Compiling in support for DBM. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. Sean MacLennan <seanm(a)seanm.ca&gt; writes: - Vin -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot [URL: http://www.cs.amherst.edu/~ccm/prufrock.html]