bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

XEmacs 21.4.10 crashes with glibc 2.3.1


From: Stephen J. Turnbull
Subject: XEmacs 21.4.10 crashes with glibc 2.3.1
Date: Mon, 04 Nov 2002 23:08:54 +0900
User-agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Military Intelligence (RC3), i686-pc-linux)

After upgrading from glibc 2.2.5 to 2.3.1 in Debian `sid', the unexec
version of XEmacs builds successfully, but crashes immediately when
invoked.  Are there reasons to believe that the new glibc might cause
problems with the unexec'd binary?  It may be related to changes in
malloc, see below.

N.B. I don't consider this a glibc bug, I just want to try to confirm
that it is related to the unexec process or malloc (we have an
alternative way to "dump" Lisp now, the so-called "portable dumper").
If it's not, it's a Heisenbug waiting to bite....

Debian version: testing/unstable (updated Mon Nov  4 19:41:15 2002)
Kernel version: Linux tleepslib 2.2.18 #1 SMP Tue Dec 26 11:36:10 JST 2000 i686 
unknown unknown GNU/Linux
glibc version:    2.3.1-3
binutils version: 2.13.90.0.10-2
gcc version:      2.95.4-12
libgcc1:          3.2.1-0pre5

(The version parts after the hyphen are Debian release numbers for the
benefit of the Debian maintainers.)  The kernel is locally compiled,
all the other packages mentioned are stock Debian sid.

XEmacs sources (for completeness):
CVSROOT=:pserver:address@hidden:/pack/xemacscvs
(password = cvs)
cvs checkout -r r21-4-10 xemacs

To reproduce the crash (my comments are in square brackets []):

------------------------------------------------------------------------

    ./configure --without-x11 --without-postgresql --with-database=no \
        --with-sound=none --without-modules --with-ncurses=no --with-gpm=no

[This gives pretty close to the minimal number of other libraries:
bash-2.05b$ ldd xemacs
        libncurses.so.5 => /lib/libncurses.so.5 (0x40022000)
        libm.so.6 => /lib/libm.so.6 (0x40061000)
        libutil.so.1 => /lib/libutil.so.1 (0x40082000)
        libc.so.6 => /lib/libc.so.6 (0x40085000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
and:]

    make

[A couple thousand lines of normal output, then:]

Dumping under the name xemacs

[So temacs works fine, and produces an xemacs by unexec.
 The following invocation of ./xemacs does NOT appear in normal make
 output due to an `@' in the Makefile.]

Testing for Lisp shadows ...
./xemacs -batch -vanilla -f list-load-path-shadows
Wrong type argument: vectorp, #<INTERNAL OBJECT (XEmacs bug?)
                     (symbol-value-forward type 7444) 0x40198008>
xemacs exiting
.
make[1]: *** [xemacs] Error 255
make[1]: Leaving directory `/playpen/Projects/XEmacs/staging/xemacs-21.4.10/src'
make: *** [src] Error 2

[This doesn't leave a core.  gdb tells me:]

bash-2.05b$ gdb xemacs 
GNU gdb 2002-08-18-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) run
Starting program: /playpen/Projects/XEmacs/staging/xemacs-21.4.10/src/xemacs 
Wrong type argument: vectorp, #<INTERNAL OBJECT (XEmacs bug?) 
(symbol-value-forward type 7444) 0x40198008>

Program exited with code 0377.
(gdb) bt
No stack.

------------------------------------------------------------------------

Add --with-system-malloc to the configure, and things proceed
normally.  This seems strange, though, because the link list is the
same except for some debugging code (vm-limits.c), while configure
says

  GNU version of malloc:             no
    - User chose not to use GNU allocators.

for the --with-system-malloc=yes case (this short-circuits all
attempts to check for special malloc features and simply uses the
<malloc.h> interface, so configure doesn't recognize GNU malloc in GNU
libc, either), while

  GNU version of malloc:             yes
    - Using Doug Lea's new malloc from the GNU C Library.

for --with-system-malloc=no.  There are a number of places where the
relevant conditional compilation (SYSTEM_MALLOC, defined in the first
case, and GNU_MALLOC and DOUG_LEA_MALLOC, defined in the second)
change usage of what look like defined malloc APIs (malloc_get_state
and malloc_set_state, before and after the unexec, it looks like).
They are used for GNU_MALLOC and DOUG_LEA_MALLOC, not used with
SYSTEM_MALLOC.  The only place where implementation details seem to be
involved is in the snippet included below.

OK, I'm stuck.  Any further information I should provide?

------------------------------------------------------------------------
#ifdef GNU_MALLOC

  if (claimed_size < 2 * sizeof (void *))
    claimed_size = 2 * sizeof (void *);
# ifdef SUNOS_LOCALTIME_BUG
  if (claimed_size < 16)
    claimed_size = 16;
# endif
  if (claimed_size < 4096)
    {
      int log = 1;

      /* compute the log base two, more or less, then use it to compute
         the block size needed. */
      claimed_size--;
      /* It's big, it's heavy, it's wood! */
      while ((claimed_size /= 2) != 0)
        ++log;
      claimed_size = 1;
      /* It's better than bad, it's good! */
      while (log > 0)
        {
          claimed_size *= 2;
          log--;
        }
      /* We have to come up with some average about the amount of
         blocks used. */
      if ((size_t) (rand () & 4095) < claimed_size)
        claimed_size += 3 * sizeof (void *);
    }
  else
    {
      claimed_size += 4095;
      claimed_size &= ~4095;
      claimed_size += (claimed_size / 4096) * 3 * sizeof (size_t);
    }

#elif defined (SYSTEM_MALLOC)

  if (claimed_size < 16)
    claimed_size = 16;
  claimed_size += 2 * sizeof (void *);

#else
------------------------------------------------------------------------

-- 
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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]