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

Previous Next

Full log

Message #20 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 20:47:31 +0200

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Fri, 30 Oct 2020 10:54:56 -0500
> Cc: 44313 <at> debbugs.gnu.org
> 
> On Fri, Oct 30, 2020 at 6:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 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.
> 
> Looks like it's non-NULL and it can't be accessed.
> 
> (lldb) p f
> (frame *) $12 = 0x00000009040f6c5d
> (lldb) p *f
> error: Couldn't apply expression side effects : Couldn't dematerialize
> a result variable: couldn't read its memory
> (lldb) p (f)->output_method
> error: supposed to interpret, but failed: Interpreter couldn't read from memory

That doesn't sound like a frame that is not live, that sounds like a
frame whose memory was freed.  Or a frame pointer that is just
garbage.

So the question now is: where did that frame pointer come from?

Previous Next

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