From owner-cvs-all@FreeBSD.ORG Fri Jan 13 13:34:58 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2772F16A431; Fri, 13 Jan 2006 13:34:58 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4621F43D4C; Fri, 13 Jan 2006 13:34:57 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-8) with SMTP id k0DDYt66005176; Fri, 13 Jan 2006 15:34:55 +0200 Received: by flame.pc (Postfix, from userid 1001) id C8C7C115BF; Fri, 13 Jan 2006 03:29:02 +0200 (EET) Date: Fri, 13 Jan 2006 03:29:01 +0200 From: Giorgos Keramidas To: Jason Evans Message-ID: <20060113012900.GA16082@flame.pc> References: <200601121809.k0CI9QGV028693@repoman.freebsd.org> <20060112182804.GA1047@flame.pc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060112182804.GA1047@flame.pc> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 13:34:58 -0000 On 2006-01-12 20:28, Giorgos Keramidas wrote: >On 2006-01-12 10:17, Jason Evans 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 # #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