GNU bug report logs - #43700
28.0.50; Crash creating a second frame

Previous Next

Full log

Message #11 received at 43700 <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 43700 <at> debbugs.gnu.org
Subject: Re: bug#43700: 28.0.50; Crash creating a second frame
Date: Tue, 29 Sep 2020 15:49:41 +0100

On 29/09/2020 15:37, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton <at> gmail.com>
>> Date: Tue, 29 Sep 2020 11:46:48 +0100
>>
>> After loading emacs (and files saved by desktop), do C-x 5 2 to create a
>> new frame. Emacs crashes, and gdb shows the following backtrace.
> 
> Is this repeatable?  Does it happen with "emacs -Q", per chance?  Or
> with unoptimized builds?

It is repeatable occasionally, but I don't yet have a recipe to 
reproduce it reliably.

It doesn't seem to happen from "emacs -Q", or from emacs --no-desktop" 
but it may be that I have not tried enough times to trigger it.

>> This seems to have something to do with toolbars, but ~/.emacs.d/init.el
>> contains "(tool-bar-mode 0)" so it shouldn't be doing anything with toolbars.
> 
> Creating a frame makes a keymap for the tool bar, whether it's
> displayed or not.
> 
> But look at this part:
> 
>> #9  0x00000004001e76b1 in FACE_FROM_ID (id=0x162880, f=0x154e25ed5d860000) at
>> C:/emacs/git/emacs/master/src/frame.h:1460
>> No locals.
>> #10 lookup_image (f=0x154e25ed5d860000, f <at> entry=0x6edbab0, spec=XIL(0),
>> spec <at> entry=XIL(0xcd2b873), face_id=0x162880, face_id <at> entry=0xffffffff) at
>> C:/emacs/git/emacs/master/src/image.c:2332
>>           img = <optimized out>
>>           hash = <optimized out>
>>           face = <optimized out>
>>           foreground = <optimized out>
>>           background = <optimized out>
>> #11 0x00000004001e8235 in Fimage_mask_p (spec=XIL(0xcd2b873), frame=XIL(0)) at
>> C:/emacs/git/emacs/master/src/image.c:1114
>>           f = 0x6edbab0
> 
> Look at the reasonable values of the arguments at entry to
> lookup_image, and the garbled values at the crash site.  The line that
> calls FACE_FROM_ID is the first executable line of lookup_image, so
> this could have happened only if the optimizations moved some
> non-trivial code between the entry to the function and that line.  Or
> maybe something else is at work here.

Something is definitely fishy. Perhaps a full bootstrap might fix it.

    AndyM

Previous Next

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