Subject: bug#71693: 30.0.50, SIGSEGV in FRAME_TTY (sf) in redisplay_internal

From: Daniel Clemente <[email-masked]>
Date: Wed, 26 Jun 2024 13:28:58 +0000

> >
> > I enabled -fsanitize. I'm using an X terminal to run TTY Emacs inside.
> > I opened the daemon inside gdb with emacs --fg-daemon -Q
>
> Did you follow the advice and notes in etc/DEBUG regarding runn ing
> Emacs compiled with this option?

I missed some things. For instance I used this:

  -fsanitize=undefined,address,bounds-strict,float-cast-overflow ''

But I didn't notice this:

Address sanitization is incompatible with undefined-behavior
sanitization, unfortunately

If you want me to enable just one for next reports, please tell me
which one. For now I think I'll disable the whole -fsanitize, because
of the false positives.

>
> > [Detaching after fork from child process 5364]
> > xdisp.c:16932:10: runtime error: member access within null pointer of
> > type 'struct terminal'
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000555556610d93 in redisplay_internal () at xdisp.c:16932
> > 16932          && FRAME_TTY (sf)->previous_frame != sf)
>
> If the claim is that sf->terminal is a NULL pointer, then how come we
> don't segfault when running a build without -fsanitize?

Even with -fsanitize, it didn't crash each time, just this particular time.

I have seen similar crashes in redisplay code even without -fsanitize,
but none at this particular line and none doing something as simple as
opening and closing 3 frames.

I also thought that maybe I had enabled so many debug options (-O0,
-fsanitize, …) that my emacs become slower and therefore more prone to
errors that depend on timing, like things happening at specific points
of the frame opening and closing code.

But this report may be bogus and you may close it if it seems so.