> If you can still reproduce it, please show the data which is involved
> in the segfault:

I'll do. I haven't been able to reproduce it. But in trying to do it I
found another crash, different code but related functions: bug#71243

I forgot whether in this case (#71224) the stack was also near the stack
limit. Maybe when it's so close to a stack overflow, these SIGSEGV can
happen first.


On Mon, 27 May 2024 at 12:16, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Daniel Clemente <n142857@gmail.com>
> > Date: Mon, 27 May 2024 11:03:49 +0000
> >
> > I ran a command to constantly open and close emacsclient TTY frames.
> > See details in the previous bug report, bug#71223
> > Copying it for reference:
> > emacs --fg-daemon -Q
> > for j in `seq 300`; do for i in `seq 10`; do urxvt -e emacsclient '-nw'
> '-e' '(dired "~")' &; done; sleep 1 && killall
> > emacsclient; done
> >
> > It crashed with SIGSEGV.
> > This happened only once in the last days, after dozens of attempts
> running that command. I can't reproduce
> > it.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > start_display (it=0x7fffffb61a60, w=0x555556fa5ae0, pos=...) at
> xdisp.c:3734
> > 3734  row = w->desired_matrix->rows + first_vpos;
>
> If you can still reproduce it, please show the data which is involved
> in the segfault:
>
>   (gdb) frame 0
>   (gdb) p w->desired_matrix
>   (gdb) p w->desired_matrix->nrows
>   (gdb) p window_wants_tab_line (w)
>   (gdb) p window_wants_header_line (w)
>
> TBH, I'm quite confused to see that line 3734 segfault, because I
> cannot understand how w->desired_matrix can be NULL or bogus.
>
> Thanks.
>