Re: dumping bug explained?

[Chip Coldwell]

On Mon, 21 May 2007, Chong Yidong wrote:

> Andreas Schwab <address@hidden> writes:
> 
> > Richard Stallman <address@hidden> writes:
> >
> >>     ** address@hidden, May 18: 22.0.99 emacs dumper (?) problem
> >>     This seems to be caused by a binary incompatible change for the malloc
> >>     implementation in glibc. The problem would occur when emacs is built
> >>     on one system and used on another. See 
> >>     https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60
> >>     for a possible complete explanation.
> >>
> >> Are people sure that this is the cause of the problem?
> >
> > There is already a patch available, see
> > <http://sourceware.org/ml/libc-hacker/2007-05/msg00015.html>.
> 
> To be precise (since RMS doesn't read URLs), this is a patch to glibc,
> not Emacs.  However, there will be released versions of glibc out
> there with this problem, so we should still document it in PROBLEMS.

Jakub Jelinek and Ulrich Drepper are working on this in glibc.  Jakub
explained it as follows: (text from
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239344#c60)

There are multiple bugs on the glibc side (unfortunately malloc_set_state the
way it is used by emacs makes many internal details of the malloc implementation
part of the ABI):
1) the
2007-04-30  Ulrich Drepper  <address@hidden>
            Jakub Jelinek  <address@hidden>

        [BZ #4349]
        * malloc/malloc.c: Keep separate list for first blocks on the bin
        lists with a given size.  This helps skipping over list elements
        we know won't fit in two places.
        Inspired by a patch by Tomash Brechko <address@hidden>.
   change affects the ABI, as if emacs is dumped with glibc before this patch
   and run with glibc after this patch, the fd_nextsize/bk_nextsize pointers
   are left uninitialized, but the new glibc relies on them having correct
   values.  This is solvable by recomputing these pointers in malloc_set_state.
2) I made an accidental commit that enabled MALLOC_DEBUG (in the
2007-05-07  Ulrich Drepper  <address@hidden>
            Jakub Jelinek  <address@hidden>

        * malloc/arena.c (heap_info): Add mprotect_size field, adjust pad.
        (new_heap): Initialize mprotect_size.
        (grow_heap): When growing, only mprotect from mprotect_size till
        new_size if mprotect_size is smaller.  When shrinking, use PROT_NONE
        MMAP for __libc_enable_secure only, otherwise use MADV_DONTNEED.
check-in) and
2007-05-13  Ulrich Drepper  <address@hidden>

        * malloc/malloc.c [MALLOC_DEBUG]: Keep track of current maximum
        number of mmaps.  n_mmaps_max is the target.
        * malloc/hooks.c: Likewise.
        * malloc/arena.c: Likewise.
change added a field to struct malloc_save_state without bumping version number.
That together means another ABI change for malloc_save_state.  We certainly
have to revert the MALLOC_DEBUG setting (that's expensive) and something
has to be done about the 05-13 change (state changing shouldn't depend on
MALLOC_DEBUG).

Chip

-- 
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
978-392-2426