cvs commit: src/lib/libc/stdlib malloc.c

[Giorgos Keramidas]

On 2006-01-12 20:28, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
>On 2006-01-12 10:17, Jason Evans <jasone at freebsd.org> wrote:
>>>  Fix a bitwise logic error in posix_memalign().
>>>
>>>  Reported by:    glebius
>>>
>>>  Revision  Changes    Path
>>>  1.92      +2 -2      src/lib/libc/stdlib/malloc.c
>>
>> If you have the misfortune of network-access cvs core dumping,
>> this will fix the problem.  There was a window of ~8.5 hours
>> during which this bug could have caused issues.
>
> Other programs misbehave here too, i.e. kldxref.  Thanks for fixing
> this :)

Hi Jason and everyone,

I don't know if this is related, and I'm in the middle of checking out
a copy of src/ before the first posix_memalign commit, with:

    $ cd /home/build/src
    $ cvs -q up -APd -D '2006/01/12 07:28:00 UTC'

to see if this makes any difference.  It seems though that the with
today's CURRENT, compiled with DEBUG_FLAGS='-g' there is a problem with
bootstrapping the CVS version of Emacs today.

I have been running cvs-emacs on FreeBSD/amd64 for a few months now
(since October), so this is probably related to the recent changes
around malloc (not sure if this is a malloc bug though, see below).
Especially since the stack backtrace of the Emacs binary that core
dumps points at:

# Generating autoloads for calendar/parse-time.el...done
# Fatal error (11)Segmentation fault (core dumped)
# gmake[2]: *** [autoloads] Error 139
# gmake[2]: Leaving directory `/home/keramida/ws/cvs-emacs/emacs/lisp'
# gmake[1]: *** [bootstrap-build] Error 2
# gmake[1]: Leaving directory `/home/keramida/ws/cvs-emacs/emacs'
# gmake: *** [bootstrap] Error 2
# $
# 
# $ gdb src/emacs-22.0.50 lisp/bootstrap-emacs.core
# #0  0x0000000800b97bac in kill () at kill.S:2
# 2       RSYSCALL(kill)
# (gdb) bt
# #0  0x0000000800b97bac in kill () at kill.S:2
# #1  0x000000000045a064 in fatal_error_signal (sig=11) at emacs.c:430
# #2  <signal handler called>
# #3  allocate_string_data (s=0x182d0a0, nchars=873, nbytes=873) at alloc.c:1981
# #4  0x00000000004abc40 in make_uninit_multibyte_string (nchars=873, nbytes=873) at alloc.c:2448
# #5  0x00000000004abcdb in make_uninit_string (length=0) at alloc.c:2428
#     [...]
# (gdb) up 3
# #3  allocate_string_data (s=0x182d0a0, nchars=873, nbytes=873) at alloc.c:1981
# 1981      s->data[nbytes] = '\0';
# (gdb) p *s
# $1 = {size = 873, size_byte = 873, intervals = 0x0, data = 0x1f16d10 "/home/keramida/ws/cvs-emacs/emacs/lisp/loaddefs.el"}
# (gdb) p nbytes
# $2 = 873
# (gdb)

The type of `s' is (struct Lisp_String), which is defined as:

    struct Lisp_String
      {
        EMACS_INT size;
        EMACS_INT size_byte;
        INTERVAL intervals;         /* text properties in this string */
        unsigned char *data;
      };

Does this look like an off-by-one error to you too Jason?  Apparently, the
allocated size of s->data is s->size, which is 873 bytes, but then Emacs tries
to access s->data[873].

Does it look like I'm right in thinking that this is a bug in Emacs?

If yes, I'd like to report this to emacs-devel at gnu.org for further
investigation by the rest of the Emacs folks :)

- Giorgos