I sent an almost identical report about getting segfaults in temacs last week, so Michael Harnois is not alone. I am using egcs-2.91.23, and glibc-2.1 ( 2.0.92 ). __________________ Richard Ketchersid +++_/_/+++_/_/++ UC Berkeley, Logic Group ++_/_/_/++_/+_/+ Office: 846 Evans +_/+++ _/+_/_/++ On Wed, 22 Apr 1998, Andreas Jaeger wrote: % % Hi, % % I'm trying to find out Michael's problem with current egcs snapshots % and current Mule-enabled XEmacsen. I do think we both have a similar % configuration (correct my Michael, if I'm wrong): quite recent egcs % 1.1 development version (in my case egcs-2.91.24 plus some patches), % glibc 2.1 development version and XEmacs development version. I know % that's too much - I don't really know whom to blame ;-). % % The problem shows up with a segmentation fault at build time: % make[1]: Entering directory `/mnt/xemacs/build-20.5/src' % EMACSBOOTSTRAPLOADPATH="/mnt/xemacs/cvs-sources/xemacs-20/src/../lisp/:/mnt/xemacs/build-20.5" ./temacs -batch -l /mnt/xemacs/cvs-sources/xemacs-20/src/../lisp/update-elc.el % make[1]: *** [update-elc.stamp] Segmentation fault % % running temacs under gdb I get: % Program received signal SIGSEGV, Segmentation fault. % 0x4028c4b9 in memcpy (dstpp=0x83ded04, srcpp=0x83debec, len=136122783) % at ../sysdeps/generic/memcpy.c:55 % (gdb) bt % #0 0x4028c4b9 in memcpy (dstpp=0x83ded04, srcpp=0x83debec, len=136122783) % at ../sysdeps/generic/memcpy.c:55 % #1 0x807dd12 in resize_string (s=0x83d917c, pos=194, delta=-136122589) % at /mnt/xemacs/cvs-sources/xemacs-20/src/alloc.c:2268 % #2 0x8082aff in set_string_char (s=0x83d917c, i=161, c=161) % at /mnt/xemacs/cvs-sources/xemacs-20/src/alloc.c:2329 % #3 0x8091e0d in complex_vars_of_casetab () % at /mnt/xemacs/cvs-sources/xemacs-20/src/casetab.c:323 % #4 0x80ad737 in xemacs_21_0_b36_i486_pc_linux (argc=5, argv=0xbffffa28, % envp=0xbffffa40, restart=0) % at /mnt/xemacs/cvs-sources/xemacs-20/src/emacs.c:1486 % #5 0x80af162 in main (argc=5, argv=0xbffffa28, envp=0xbffffa40) % at /mnt/xemacs/cvs-sources/xemacs-20/src/emacs.c:2019 % #6 0x40245d06 in __libc_start_main (main=0x80af100 <main>, argc=5, % argv=0xbffffa28, init=0x8079870 <_init>, fini=0x81cb4f0 <_fini>, % rtld_fini=0x4000a580 <_dl_fini>) at ../sysdeps/generic/libc-start.c:72 % % debugging into set_string_char I get: % % Breakpoint 3, set_string_char (s=0x83d917c, i=159, c=159) % at /mnt/xemacs/cvs-sources/xemacs-20/src/alloc.c:2328 % 3: bytoff = 190 % 2: newlen = 3 % 1: oldlen = 3 % Breakpoint 3, set_string_char (s=0x83d917c, i=160, c=160) % at /mnt/xemacs/cvs-sources/xemacs-20/src/alloc.c:2328 % 3: bytoff = 192 % 2: newlen = 3 % 1: oldlen = 4 % % And naturally the program fails since oldlen > newlen: % if (oldlen != newlen) % resize_string (s, bytoff, newlen - oldlen); % % Ok, what's so special about character 160 that it fails for this % single character? The glibc 2.1 test program for islower and friends % outputs the following characteristics: % 160/'\240' iscntrl; lower = 160/'\240'; upper = 160/'\240' % % Has anybody any ideas what's wrong? Why is oldlen > newlen? Any % ideas what I can check? % % Andreas %