GNU bug report logs - #45541
28.0.50; Frequent crashes on ARM macOS

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Philipp Stephani <p.stephani2 <at> gmail.com>, 45541 <at> debbugs.gnu.org
Subject: bug#45541: 28.0.50; Frequent crashes on ARM macOS
Date: Wed, 30 Dec 2020 15:53:01 +0100

Am Mi., 30. Dez. 2020 um 15:49 Uhr schrieb Philipp Stephani
<p.stephani2 <at> gmail.com>:
>
> Am Mi., 30. Dez. 2020 um 15:42 Uhr schrieb Philipp Stephani
> <p.stephani2 <at> gmail.com>:
> >
> > Am Mi., 30. Dez. 2020 um 15:05 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > >
> > > On Wed, Dec 30, 2020 at 02:01:18PM +0100, Philipp Stephani wrote:
> > > > Am Mi., 30. Dez. 2020 um 01:10 Uhr schrieb Alan Third <alan <at> idiocy.org>:
> > > > >
> > > > > On Tue, Dec 29, 2020 at 11:32:43PM +0100, Philipp wrote:
> > > > > >
> > > > > > With an Emacs built from the emacs-27 branch I get frequent crashes on
> > > > > > ARM64 macOS (Big Sur).  I haven't managed to produce an Elisp stacktrace
> > > > > > yet, but here's the crash report:
> > > > > <snip>
> > > > > > Looks like a crash in ns_mouse_position.
> > > > >
> > > > > Can you check that the build includes this?
> > > > >
> > > > > 6aa9fe3e1b4052b2acde86404a90e35893ebfa00?
> > > > > Fix crash in ns_mouse_position (bug#44313)
> > > >
> > > > Yes, according to "git branch --contains" the commit is present.  The
> > > > exception report makes me think that NSApp is null or invalid, but how
> > > > should that be possible?
> > >
> > > I have no idea... What's happening when the crash occurs? I take it
> > > the mouse is being moved, but are frames opening and closing or
> > > anything?
> >
> > I'm now able to reproduce this consistently. It happens when a tooltip
> > appears and you hover over that tooltip (try M-x locate and move the
> > mouse around).
> > The crash is in the line
> >   if (f && FRAME_NS_P (f))
> > in nsterm.m in ns_mouse_position, so apparently "f" is not NULL, but
> > also not valid.
>
> Looks like "f" isn't initialized to NULL in that function?

This was probably fixed with commit
b4911a6f0da0bfae3832b3aa0c111db4bb2f49d5 on master. I guess we should
backport the one-line initialization change onto the release branch,
since the crash is nasty and the fix is trivial.

Previous Next

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