Date: Fri, 13 Jan 2006 03:29:01 +0200 From: Giorgos Keramidas <keramida@FreeBSD.org> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060113012900.GA16082@flame.pc> In-Reply-To: <20060112182804.GA1047@flame.pc> References: <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <20060112182804.GA1047@flame.pc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-01-12 20:28, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
>On 2006-01-12 10:17, Jason Evans <jasone@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@gnu.org for further
investigation by the rest of the Emacs folks :)
- Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060113012900.GA16082>