> 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.