GNU bug report logs - #44313
27.1.50; ns_mouse_position EXC_BAD_ACCESS crash

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: 44313 <at> debbugs.gnu.org
Subject: Re: bug#44313: 27.1.50; ns_mouse_position EXC_BAD_ACCESS crash
Date: Fri, 30 Oct 2020 13:29:31 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 05:16:35 -0500
> Cc: 44313 <at> debbugs.gnu.org
> 
> >   if (f && FRAME_NS_P (f))
> >
> > So why does FRAME_NS_P crash? which part of the frame's structure are
> > invalid?
> 
> I believe that macro is defined as:
> 
>     #define FRAME_NS_P(f) ((f)->output_method == output_ns)
> 
> Would the de-reference cause an EXC_BAD_ACCESS if the frame had been released?

If f is non-NULL, I don't think it could case EXC_BAD_ACCESS, unless f
is garbled and points outside of the process's address space.  Which
is why we need to see the value of f and whether the address it points
to could be accessed.

> I make use of child frames via the posframe packages. I wonder if
> something requested a mouse pixel position for a frame either as it
> was being released or after it was being released?

For this, we need to see the Lisp-level backtrace at the crash.
Sadly, AFAIK lldb doesn't support the commands in src/.gdbinit, so the
only way to generate this I know of is to manually show the function
called by each Funcall in the C backtrace.  Which is quite tedious.

Previous Next

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