GNU bug report logs - #44047
current HEAD has been crashing on startup

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44047 in the body.
You can then email your comments to 44047 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: current HEAD has been crashing on startup
Date: Sat, 17 Oct 2020 11:06:23 -0600 (MDT)

I waited a few days before reporting this because I'm not sure how much 
useful information I can provide in this report, but it hasn't been 
mentioned by anyone else, so here goes.

Running ./emacs in src/ within gdb (invoking it with -Q), I'm getting:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.

build_frame_matrix_from_leaf_window (w=0x555555b8c140,
    frame_matrix=<optimized out>) at dispnew.c:2531
2531          fill_up_frame_row_with_spaces (frame_row, 
window_matrix->matrix_x);

This is on a Linux 5.7 kernel, Debian unstable, x86-64, but I can 
replicate it on a raspi running 5.4 and stable.

It appears to be related to -nw somehow; using that triggers the crash on 
the Pi (otherwise it starts up normally).

On the first machine, configure options are "--with-x-toolkit=no 
--without-x --with-mailutils --enable-link-time-optimization".

I'm sorry I can't be more detailed, but it's kind of hard to run M-x
report-emacs-bug under the circumstances. I can, of course, test any 
patches.


-- 
Liam Stitt
stittl <at> cuug.ab.ca

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Sat, 17 Oct 2020 20:15:34 +0300

> Date: Sat, 17 Oct 2020 11:06:23 -0600 (MDT)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> 
> 
> I waited a few days before reporting this because I'm not sure how much 
> useful information I can provide in this report, but it hasn't been 
> mentioned by anyone else, so here goes.
> 
> Running ./emacs in src/ within gdb (invoking it with -Q), I'm getting:
> 
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 
> Program received signal SIGSEGV, Segmentation fault.
> 
> build_frame_matrix_from_leaf_window (w=0x555555b8c140,
>      frame_matrix=<optimized out>) at dispnew.c:2531
> 2531          fill_up_frame_row_with_spaces (frame_row, 
> window_matrix->matrix_x);
> 
> This is on a Linux 5.7 kernel, Debian unstable, x86-64, but I can 
> replicate it on a raspi running 5.4 and stable.
> 
> It appears to be related to -nw somehow; using that triggers the crash on 
> the Pi (otherwise it starts up normally).

You are saying that "./src/emacs -Q -nw" crashes on startup?  That
doesn't happen to me with today's master branch.

Can you build an unoptimized version, run it under GDB, and when it
crashes, show a backtrace?

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Sun, 18 Oct 2020 19:10:12 -0600 (MDT)

On Sat, 17 Oct 2020, Eli Zaretskii wrote:

> You are saying that "./src/emacs -Q -nw" crashes on startup?  That
> doesn't happen to me with today's master branch.

Yes. It is only happening on Linux; I can build without problems on OS X.

> Can you build an unoptimized version, run it under GDB, and when it
> crashes, show a backtrace?

Does building the unoptimized version require more than tweaking the 
CFLAGS entry in src/Makefile? If not, this is what I got:

(gdb) run -Q -nw
Starting program: /home/frink/src/emacs/src/emacs -Q -nw
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff188e700 (LWP 2901333)]
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.

0x0000555555598126 in fill_up_frame_row_with_spaces (row=0x100, upto=0)
    at dispnew.c:2660
2660      int i = row->used[TEXT_AREA];
(gdb) bt
#0  0x0000555555598126 in fill_up_frame_row_with_spaces (row=0x100, 
upto=0)
    at dispnew.c:2660
#1  0x0000555555597de8 in build_frame_matrix_from_leaf_window
    (frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
#2  0x0000555555597ba4 in build_frame_matrix_from_window_tree
    (matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2465
#3  0x0000555555597b40 in build_frame_matrix (f=0x555555d421b8)
    at dispnew.c:2449
#4  0x0000555555599364 in update_frame
    (f=0x555555d421b8, force_p=true, inhibit_hairy_id_p=true) at 
dispnew.c:3236
#5  0x00005555555d97b5 in echo_area_display (update_frame_p=true)
    at xdisp.c:12210
#6  0x00005555555d64f0 in message3_nolog (m=XIL(0x555555eb3344))
    at xdisp.c:11141
#7  0x00005555555d6261 in message3 (m=XIL(0x555555eb3344)) at 
xdisp.c:11071
#8  0x000055555579265e in Fmessage (nargs=2, args=0x7fffffffbf90)
    at editfns.c:2854
#9  0x00005555557a069a in funcall_subr
    (subr=0x555555c42980 <Smessage>, numargs=2, args=0x7fffffffbf90)
    at eval.c:2859
#10 0x00005555557a0388 in Ffuncall (nargs=3, args=0x7fffffffbf88)
    at eval.c:2806
#11 0x00005555557ea7a5 in exec_byte_code
    (bytestr=XIL(0x7ffff22d7b24), vector=XIL(0x7ffff22d79f5), 
maxdepth=make_fixnum(7), args_template=make_fixnum(0), nargs=0, 
args=0x7fffffffc4d8)
    at bytecode.c:632
#12 0x00005555557a0a27 in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22d79cd), syms_left=make_fixnum(0), nargs=0, 
args=0x7fffffffc4d8) at eval.c:2928
#13 0x00005555557a0db4 in funcall_lambda
    (fun=XIL(0x7ffff22d79cd), nargs=0, arg_vector=0x7fffffffc4d8)
    at eval.c:3009
#14 0x00005555557a03cc in Ffuncall (nargs=1, args=0x7fffffffc4d0)
    at eval.c:2808
#15 0x00005555557ea7a5 in exec_byte_code
    (bytestr=XIL(0x7ffff22d7b64), vector=XIL(0x7ffff22d684d), 
maxdepth=make_fixnum(25), args_template=make_fixnum(257), nargs=1, 
args=0x7fffffffceb8)
    at bytecode.c:632
#16 0x00005555557a0a27 in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22d681d), syms_left=make_fixnum(257), nargs=1, 
args=0x7fffffffceb0) at eval.c:2928
#17 0x00005555557a0db4 in funcall_lambda
    (fun=XIL(0x7ffff22d681d), nargs=1, arg_vector=0x7fffffffceb0)
    at eval.c:3009
#18 0x00005555557a03cc in Ffuncall (nargs=2, args=0x7fffffffcea8)
    at eval.c:2808
#19 0x00005555557ea7a5 in exec_byte_code
    (bytestr=XIL(0x7ffff22db2ec), vector=XIL(0x7ffff22d7db5), 
maxdepth=make_fixnum(14), args_template=make_fixnum(0), nargs=0, 
args=0x7fffffffda28)
    at bytecode.c:632
#20 0x00005555557a0a27 in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22d7d85), syms_left=make_fixnum(0), nargs=0, 
args=0x7fffffffda28) at eval.c:2928
#21 0x00005555557a0db4 in funcall_lambda
    (fun=XIL(0x7ffff22d7d85), nargs=0, arg_vector=0x7fffffffda28)
    at eval.c:3009
#22 0x00005555557a03cc in Ffuncall (nargs=1, args=0x7fffffffda20)
    at eval.c:2808
#23 0x00005555557ea7a5 in exec_byte_code
    (bytestr=XIL(0x7ffff22dbfb4), vector=XIL(0x7ffff22db4bd), 
maxdepth=make_fixnum(12), args_template=make_fixnum(0), nargs=0, 
args=0x7fffffffe0a0)
    at bytecode.c:632
#24 0x00005555557a0a27 in fetch_and_exec_byte_code
    (fun=XIL(0x7ffff22db48d), syms_left=make_fixnum(0), nargs=0, 
args=0x7fffffffe0a0) at eval.c:2928
#25 0x00005555557a0db4 in funcall_lambda
    (fun=XIL(0x7ffff22db48d), nargs=0, arg_vector=0x7fffffffe0a0)
    at eval.c:3009
#26 0x00005555557a0bd1 in apply_lambda
    (fun=XIL(0x7ffff22db48d), args=XIL(0), count=4) at eval.c:2953
#27 0x000055555579effc in eval_sub (form=XIL(0x7ffff243625b)) at 
eval.c:2328
#28 0x000055555579e4f9 in Feval (form=XIL(0x7ffff243625b), lexical=XIL(0))
    at eval.c:2112
#29 0x00005555556e7c82 in top_level_2 () at keyboard.c:1104
#30 0x000055555579cbfe in internal_condition_case
    (bfun=0x5555556e7c5f <top_level_2>, handlers=XIL(0x90), 
hfun=0x5555556e770b <cmd_error>) at eval.c:1356
#31 0x00005555556e7cca in top_level_1 (ignore=XIL(0)) at keyboard.c:1112
#32 0x000055555579c4b3 in internal_catch
    (tag=XIL(0xd290), func=0x5555556e7c84 <top_level_1>, arg=XIL(0))
    at eval.c:1117
#33 0x00005555556e7bad in command_loop () at keyboard.c:1073
#34 0x00005555556e72dc in recursive_edit_1 () at keyboard.c:718
#35 0x00005555556e745f in Frecursive_edit () at keyboard.c:790
#36 0x00005555556e3f7d in main (argc=3, argv=0x7fffffffe618) at 
emacs.c:2047

Lisp Backtrace:
"message" (0xffffbf90)
"display-startup-echo-area-message" (0xffffc4d8)
"command-line-1" (0xffffceb0)
"command-line" (0xffffda28)
"normal-top-level" (0xffffe0a0)
(gdb)



-- 
Liam Stitt
stittl <at> cuug.ab.ca

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Mon, 19 Oct 2020 17:23:26 +0300

> Date: Sun, 18 Oct 2020 19:10:12 -0600 (MDT)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> cc: 44047 <at> debbugs.gnu.org
> 
> > Can you build an unoptimized version, run it under GDB, and when it
> > crashes, show a backtrace?
> 
> Does building the unoptimized version require more than tweaking the 
> CFLAGS entry in src/Makefile? If not, this is what I got:

Thanks.  Please reproduce the crash again, and this time say

  (gdb) bt full

and post everything that produces.

> 0x0000555555598126 in fill_up_frame_row_with_spaces (row=0x100, upto=0)
                                                       ^^^
That 'row' pointer is clearly bogus (and causes the crash).  The
question is how does this happen.  I hope the output of "bt full" will
give some ideas.

Thanks.

P.S. Is this on some terminal emulator?  If so, which one (xterm,
something else?), and what are the dimensions of the terminal window
where you invoke Emacs?

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Mon, 19 Oct 2020 10:28:32 -0600 (MDT)

[Message part 1 (text/plain, inline)]

On Mon, 19 Oct 2020, Eli Zaretskii wrote:

>  (gdb) bt full
> and post everything that produces.

That being 40K of output, I have attached it to this reply.

> P.S. Is this on some terminal emulator?  If so, which one (xterm,
> something else?), and what are the dimensions of the terminal window
> where you invoke Emacs?

screen(1), via ssh from iTerm2 on osx; the window is 80x26.


-- 
Liam Stitt
stittl <at> cuug.ab.ca

[gdb-44047.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Mon, 19 Oct 2020 20:08:50 +0300

> Date: Mon, 19 Oct 2020 10:28:32 -0600 (MDT)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> cc: 44047 <at> debbugs.gnu.org
> 
> >  (gdb) bt full
> > and post everything that produces.
> 
> That being 40K of output, I have attached it to this reply.

Thanks.  What does this produce:

  (gdb) frame 1
  (gdb) print window_matrix->rows
  (gdb) print window_matrix->nrows

> > P.S. Is this on some terminal emulator?  If so, which one (xterm,
> > something else?), and what are the dimensions of the terminal window
> > where you invoke Emacs?
> 
> screen(1), via ssh from iTerm2 on osx; the window is 80x26.

What are the values of the following 3 environment variables on the
remote system: TERM, COLUMNS, LINES?

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Mon, 19 Oct 2020 22:39:03 -0600 (MDT)

On Mon, 19 Oct 2020, Eli Zaretskii wrote:

>  (gdb) frame 1
>  (gdb) print window_matrix->rows
>  (gdb) print window_matrix->nrows

(gdb) frame 1
#1  0x0000555555597de8 in build_frame_matrix_from_leaf_window (
    frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
2531          fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
(gdb) print window_matrix->rows
$1 = (struct glyph_row *) 0x555555d7b170
(gdb) print window_matrix->nrows
$2 = 24

>> screen(1), via ssh from iTerm2 on osx; the window is 80x26.
> What are the values of the following 3 environment variables on the
> remote system: TERM, COLUMNS, LINES?

screen, 80, and 26; but te latter two are the shell builtins and not 
existing environment variables.


-- 
Liam Stitt
stittl <at> cuug.ab.ca

fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Tue, 20 Oct 2020 18:48:12 +0300

> Date: Mon, 19 Oct 2020 22:39:03 -0600 (MDT)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> cc: 44047 <at> debbugs.gnu.org
> 
> On Mon, 19 Oct 2020, Eli Zaretskii wrote:
> 
> >  (gdb) frame 1
> >  (gdb) print window_matrix->rows
> >  (gdb) print window_matrix->nrows
> 
> (gdb) frame 1
> #1  0x0000555555597de8 in build_frame_matrix_from_leaf_window (
>      frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
> 2531          fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
> (gdb) print window_matrix->rows
> $1 = (struct glyph_row *) 0x555555d7b170
> (gdb) print window_matrix->nrows
> $2 = 24

Thanks.  How about this:

  (gdb) frame 1
  (gdb) print frame_matrix->rows
  (gdb) print frame_matrix->nrows

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Tue, 20 Oct 2020 16:19:26 -0600 (MDT)

On Tue, 20 Oct 2020, Eli Zaretskii wrote:

>  (gdb) frame 1
>  (gdb) print frame_matrix->rows
>  (gdb) print frame_matrix->nrows

(gdb) frame 1
#1  0x0000555555597de8 in build_frame_matrix_from_leaf_window (
    frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
2531          fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
(gdb) print frame_matrix->rows
$1 = (struct glyph_row *) 0x0
(gdb) print frame_matrix->nrows
$2 = 0


-- 
Liam Stitt
stittl <at> cuug.ab.ca

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Wed, 21 Oct 2020 19:03:20 +0300

> Date: Tue, 20 Oct 2020 16:19:26 -0600 (MDT)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> cc: 44047 <at> debbugs.gnu.org
> 
> (gdb) frame 1
> #1  0x0000555555597de8 in build_frame_matrix_from_leaf_window (
>      frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
> 2531          fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
> (gdb) print frame_matrix->rows
> $1 = (struct glyph_row *) 0x0
> (gdb) print frame_matrix->nrows
> $2 = 0

OK, so this is the problem: the frame glyph matrix has no glyph rows
allocated to it.  The question is how did that happen?

To find out, please run Emacs under GDB, after setting a breakpoint in
adjust_frame_glyphs_for_frame_redisplay:

  (gdb) break adjust_frame_glyphs_for_frame_redisplay
  (gdb) run -Q -nw

When the breakpoint breaks, step through the code with the "next"
command.  The first couple of times when the function is called, it
should return immediately, here:

  if (!FRAME_LIVE_P (f))
    return;

In the call after those 2, it should allocate the glyph pools and the
2 glyph matrices, then call allocate_matrices_for_frame_redisplay, and
return here:

	  if (!FRAME_WINDOW_P (f) && pool_changed_p)
	    SET_FRAME_GARBAGED (f);
	  return;

And in the next call, it should in addition allocate the glyph rows,
here:

      else
	{
	  adjust_glyph_matrix (NULL, f->desired_matrix, 0, 0, matrix_dim);
	  adjust_glyph_matrix (NULL, f->current_matrix, 0, 0, matrix_dim);
	  SET_FRAME_GARBAGED (f);
	}

This last call's backtrace should look like this:

  (gdb) bt
  #0  adjust_frame_glyphs_for_frame_redisplay (f=0xf46948) at dispnew.c:2008
  #1  0x000000000041c905 in adjust_frame_glyphs (f=0xf46948) at dispnew.c:1828
  #2  0x000000000042cdfd in adjust_frame_size (f=0xf46948, new_width=80,
      new_height=37, inhibit=5, pretend=false, parameter=XIL(0x3690))
      at frame.c:819
  #3  0x0000000000427657 in change_frame_size_1 (f=0xf46948, new_width=80,
      new_height=37, pretend=false, delay=false, safe=true, pixelwise=false)
      at dispnew.c:5798
  #4  0x00000000004276aa in change_frame_size (f=0xf46948, new_width=80,
      new_height=37, pretend=false, delay=false, safe=true, pixelwise=false)
      at dispnew.c:5830
  #5  0x00000000004290e2 in init_display_interactive () at dispnew.c:6397
  #6  0x0000000000429561 in init_display () at dispnew.c:6449
  #7  0x00000000005a892b in main (argc=3, argv=0x7fffffffe538) at emacs.c:1995

Does this happen to you as I described, or does something different
happen?

Also, each time allocate_matrices_for_frame_redisplay is called,
please show the value of matrix_dim after the call:

  (gdb) p matrix_dim

and also show the value of f->total_lines each time
adjust_frame_glyphs_for_frame_redisplay is called:

  (gdb) p f->total_lines.

Finally, the last time adjust_frame_glyphs_for_frame_redisplay is
called, and goes on through all of its code, you should see non-NULL
value of the frame's glyph_matrix's glyph_rows before the function
returns.  Here's what I see:

  (gdb) p f->desired_matrix->rows
  $11 = (struct glyph_row *) 0xf50140
  (gdb) p f->desired_matrix->nrows
  $12 = 38

(In my case, the TTY window has height of 38 lines.)

If what happens on your system matches the above description, then
somehow the value of f->desired_matrix->rows is NULLified after this
initialization.  But if you get NULL as f->desired_matrix->rows in the
last call to adjust_frame_glyphs_for_frame_redisplay, or if Emacs
segfaults before it reaches that point, then something abnormal
happens during initialization, and we will next look at that.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: stittl <at> cuug.ab.ca
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Mon, 26 Oct 2020 17:12:39 +0200

Ping!  Any news on this?

> Date: Wed, 21 Oct 2020 19:03:20 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 44047 <at> debbugs.gnu.org
> 
> > Date: Tue, 20 Oct 2020 16:19:26 -0600 (MDT)
> > From: Liam Stitt <stittl <at> cuug.ab.ca>
> > cc: 44047 <at> debbugs.gnu.org
> > 
> > (gdb) frame 1
> > #1  0x0000555555597de8 in build_frame_matrix_from_leaf_window (
> >      frame_matrix=0x555555d4a2b0, w=0x555555d42420) at dispnew.c:2531
> > 2531          fill_up_frame_row_with_spaces (frame_row, window_matrix->matrix_x);
> > (gdb) print frame_matrix->rows
> > $1 = (struct glyph_row *) 0x0
> > (gdb) print frame_matrix->nrows
> > $2 = 0
> 
> OK, so this is the problem: the frame glyph matrix has no glyph rows
> allocated to it.  The question is how did that happen?
> 
> To find out, please run Emacs under GDB, after setting a breakpoint in
> adjust_frame_glyphs_for_frame_redisplay:
> 
>   (gdb) break adjust_frame_glyphs_for_frame_redisplay
>   (gdb) run -Q -nw
> 
> When the breakpoint breaks, step through the code with the "next"
> command.  The first couple of times when the function is called, it
> should return immediately, here:
> 
>   if (!FRAME_LIVE_P (f))
>     return;
> 
> In the call after those 2, it should allocate the glyph pools and the
> 2 glyph matrices, then call allocate_matrices_for_frame_redisplay, and
> return here:
> 
> 	  if (!FRAME_WINDOW_P (f) && pool_changed_p)
> 	    SET_FRAME_GARBAGED (f);
> 	  return;
> 
> And in the next call, it should in addition allocate the glyph rows,
> here:
> 
>       else
> 	{
> 	  adjust_glyph_matrix (NULL, f->desired_matrix, 0, 0, matrix_dim);
> 	  adjust_glyph_matrix (NULL, f->current_matrix, 0, 0, matrix_dim);
> 	  SET_FRAME_GARBAGED (f);
> 	}
> 
> This last call's backtrace should look like this:
> 
>   (gdb) bt
>   #0  adjust_frame_glyphs_for_frame_redisplay (f=0xf46948) at dispnew.c:2008
>   #1  0x000000000041c905 in adjust_frame_glyphs (f=0xf46948) at dispnew.c:1828
>   #2  0x000000000042cdfd in adjust_frame_size (f=0xf46948, new_width=80,
>       new_height=37, inhibit=5, pretend=false, parameter=XIL(0x3690))
>       at frame.c:819
>   #3  0x0000000000427657 in change_frame_size_1 (f=0xf46948, new_width=80,
>       new_height=37, pretend=false, delay=false, safe=true, pixelwise=false)
>       at dispnew.c:5798
>   #4  0x00000000004276aa in change_frame_size (f=0xf46948, new_width=80,
>       new_height=37, pretend=false, delay=false, safe=true, pixelwise=false)
>       at dispnew.c:5830
>   #5  0x00000000004290e2 in init_display_interactive () at dispnew.c:6397
>   #6  0x0000000000429561 in init_display () at dispnew.c:6449
>   #7  0x00000000005a892b in main (argc=3, argv=0x7fffffffe538) at emacs.c:1995
> 
> Does this happen to you as I described, or does something different
> happen?
> 
> Also, each time allocate_matrices_for_frame_redisplay is called,
> please show the value of matrix_dim after the call:
> 
>   (gdb) p matrix_dim
> 
> and also show the value of f->total_lines each time
> adjust_frame_glyphs_for_frame_redisplay is called:
> 
>   (gdb) p f->total_lines.
> 
> Finally, the last time adjust_frame_glyphs_for_frame_redisplay is
> called, and goes on through all of its code, you should see non-NULL
> value of the frame's glyph_matrix's glyph_rows before the function
> returns.  Here's what I see:
> 
>   (gdb) p f->desired_matrix->rows
>   $11 = (struct glyph_row *) 0xf50140
>   (gdb) p f->desired_matrix->nrows
>   $12 = 38
> 
> (In my case, the TTY window has height of 38 lines.)
> 
> If what happens on your system matches the above description, then
> somehow the value of f->desired_matrix->rows is NULLified after this
> initialization.  But if you get NULL as f->desired_matrix->rows in the
> last call to adjust_frame_glyphs_for_frame_redisplay, or if Emacs
> segfaults before it reaches that point, then something abnormal
> happens during initialization, and we will next look at that.
> 
> Thanks.
> 
> 
> 
> 

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

From: Liam Stitt <stittl <at> cuug.ab.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44047 <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Sun, 1 Nov 2020 06:48:45 -0700 (MST)

On Mon, 26 Oct 2020, Eli Zaretskii wrote:

> Ping!  Any news on this?

Belatedly, yes: the problem spontaneously went away(!), after I 
accidentally full-screened my terminal emulator then restored it to 
normal size. While I am by no means certain of why that should have
such an effect, what digging I have been able to do suggests the
explanation might involve (1) a SIGWINCH that operation generated which 
(2) caused that particular screen-sessions's bash to set $COLUMNS and 
$LINES, which were previously nonextant.

I haven't been able to replicate the crash since. I can only suggest 
closing this bug report for now, and I'll reopen it if I manage to
figure out how to trigger the crash again.


-- 
Liam Stitt
stittl <at> cuug.ab.ca

Message #43 received at 44047-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Stitt <stittl <at> cuug.ab.ca>
Cc: 44047-done <at> debbugs.gnu.org
Subject: Re: bug#44047: current HEAD has been crashing on startup
Date: Sun, 01 Nov 2020 17:34:43 +0200

> Date: Sun, 1 Nov 2020 06:48:45 -0700 (MST)
> From: Liam Stitt <stittl <at> cuug.ab.ca>
> cc: 44047 <at> debbugs.gnu.org
> 
> > Ping!  Any news on this?
> 
> Belatedly, yes: the problem spontaneously went away(!), after I 
> accidentally full-screened my terminal emulator then restored it to 
> normal size. While I am by no means certain of why that should have
> such an effect, what digging I have been able to do suggests the
> explanation might involve (1) a SIGWINCH that operation generated which 
> (2) caused that particular screen-sessions's bash to set $COLUMNS and 
> $LINES, which were previously nonextant.
> 
> I haven't been able to replicate the crash since. I can only suggest 
> closing this bug report for now, and I'll reopen it if I manage to
> figure out how to trigger the crash again.

OK, thanks.  Done.

Previous Next

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