GNU bug report logs - #16901
24.3.50; emacs_backtrace.txt

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: lekktu <at> gmail.com
Cc: 16901 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
Subject: bug#16901: 24.3.50; emacs_backtrace.txt
Date: Mon, 03 Mar 2014 18:54:08 +0200

> Date: Sun, 02 Mar 2014 19:00:23 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 16901 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
> 
> > From: Juanma Barranquero <lekktu <at> gmail.com>
> > Date: Sun, 2 Mar 2014 05:16:29 +0100
> > Cc: Drew Adams <drew.adams <at> oracle.com>, Dmitry Antipov <dmantipov <at> yandex.ru>, 16901 <at> debbugs.gnu.org
> > 
> > If you rebuild gmalloc.c with an added #define GC_MCHECK, do you see
> > the mabort calls too?
> 
> Yes, I see them, and I'm looking into that.  Which requires me to wade
> through some completely obfuscated code first...

I fixed 2 bugs in gmalloc (trunk revision 116643).  One of them was in
the GC_MCHECK code, but the other could have been triggered in a
normal build as well (although a GC_MCHECK build triggered it all the
time).  In a nutshell, gmalloc didn't cope well with aligned
allocations, especially when GC_MCHECK was turned on.

The result survived a full bootstrap, where the original code couldn't
even get past loading the *.el files into bootstrap-emacs during the
initial build of the trunk, and of course the crasher with HELLO
reported by Juanma no longer does.

So I think this is ready for prime time, and let's hope it will reveal
real problems.

P.S. The bugs in gmalloc were so glaring that I'd appreciate if
someone could eyeball my changes, in case I grossly misunderstood the
code.  When I see such bugs in such veteran code, I usually question
my own sanity.  TIA.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.