GNU bug report logs - #21666
25.0.50; Random segfaults

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org
Subject: bug#21666: 25.0.50; Random segfaults
Date: Sat, 17 Oct 2015 11:06:34 +0300

> Cc: jorgen.schaefer <at> gmail.com, 21666 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 16 Oct 2015 15:28:44 -0700
> 
> On 10/16/2015 02:03 AM, Eli Zaretskii wrote:
> > Do I read the backtrace correctly to indicate that Fabs was called
> > with an argument that is a symbol, not a number?
> 
> No, Fabs's argument is 95, which means its tag is 7, which is 
> Lisp_Float. Applying XFLOAT to 95 yields (struct Lisp_Float *) 0x58, 
> which is not a valid pointer.
> 
> The new backtrace contains a call to Fmapcar, so it could well be that 
> the problem is mapcar-related. However, my hypothesis does not look 
> right, because this code has been patched so that sa_must_free is false, 
> which means mapcar's temporary array of Lisp_Object values is allocated 
> on the C stack and not via malloc. I'm afraid this means I am at a loss.

Stack corruption might be caused by overrunning the bounds of an
automatic array, or by calling a function that overwrites the bounds
of its array argument.  Maybe using some debugging libraries or GCC
options for these problems could catch the bad code?

Another idea is to look at values in addresses adjacent to the one
where this Lisp_Float was stored.  0x58 is a code of an ASCII
character (and so is 95 = 0x5F), so perhaps we have some ASCII text
around there.  If so, and if we can recognize that text, that could
give us some hints as to where to look for the villain.

Previous Next

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