GNU bug report logs - #71693
30.0.50, SIGSEGV in FRAME_TTY (sf) in redisplay_internal

Previous Next

To reply to this bug, email your comments to 71693 AT debbugs.gnu.org.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Clemente <n142857 <at> gmail.com>
Cc: 71693 <at> debbugs.gnu.org
Subject: Re: bug#71693: 30.0.50,
 SIGSEGV in FRAME_TTY (sf) in redisplay_internal
Date: Fri, 21 Jun 2024 17:18:07 +0300

> From: Daniel Clemente <n142857 <at> gmail.com>
> Date: Fri, 21 Jun 2024 10:46: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?

> [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?

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

From: Daniel Clemente <n142857 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71693 <at> debbugs.gnu.org
Subject: Re: bug#71693: 30.0.50,
 SIGSEGV in FRAME_TTY (sf) in redisplay_internal
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.

Previous Next

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