GNU bug report logs - #76427
31.0.50; feature/igc: terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:425

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregor Zattler <telegraph <at> gmx.net>
Cc: 76427 <at> debbugs.gnu.org
Subject: Re: bug#76427: 31.0.50;
 feature/igc: terminate_due_to_signal (sig=sig <at> entry=6,
 backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:425
Date: Thu, 20 Feb 2025 09:05:30 +0200

> Date: Thu, 20 Feb 2025 00:18:54 +0100
> From:  Gregor Zattler via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Dear Emacs developers, while working
> with org-noter and pdf-tools, Emacs
> crashed.

It isn't a crash, it's an assertion violation, here:

      FOR_EACH_FRAME (tail, frame)
	{
	  struct frame *f = XFRAME (frame);
	  struct window *w = XWINDOW (FRAME_SELECTED_WINDOW (f));
	  if (some_windows
	      && !f->redisplay
	      && !w->redisplay
	      && !XBUFFER (w->contents)->text->redisplay) <<<<<<<<<<<<<<<<
	    continue;

> I would not know how to reproduce.

Like so:

 (gdb) fr 4
 (gdb) pp Vframe_list

This should show a list such as below:

  (#<frame xdisp.c 1115b968> #<frame *scratch* 0b6ac718>)

where each member shows the buffer and the C pointer to the frame
structure.  What does it show in your case?  The assertion violation
seems to imply that one of the frames has its selected window be
either corrupted or not a leaf window (which should never happen) or
maybe not a window object at all.

Given the above value of Vframe_list, please show the value of the
'->contents' field of each frame's selected window.  Like this:

  (gdb) p XWINDOW(((struct frame *)0x1115b968)->selected_window)->contents
  $4 = XIL(0xa00000000b6a7a10)
  (gdb) xtype
  Lisp_Vectorlike
  PVEC_BUFFER

Here, the value 0x1115b968 was taken from the first member of
Vframe_list shown above; it will be different in your case.  The
results in my case are that the ->contents field of the window is a
buffer, as expected.  But in your case, for one of the frames in the
list the ->contents field will be something other than a buffer, which
is what triggers the assertion.  So keep typing the above commands for
every frame in the Vframe_list list until you get to the problematic
frame.  (It would be easier to do all this using the frame pointer in
the local variable 'f', but since you are using an optimized build,
that variable is "optimized out" (which is a GDB euphemism for "I
don't know where its value is stored"), so we cannot use that.)

Thanks.

Previous Next

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