Re: Michael Harnois' problem with egcs/Mule
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
%