[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24581: 25.1 crash in ns_scroll_run after closing a frame
From: |
Alan Third |
Subject: |
bug#24581: 25.1 crash in ns_scroll_run after closing a frame |
Date: |
Sat, 1 Oct 2016 21:35:03 +0100 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Sat, Oct 01, 2016 at 10:17:24AM -0400, David Reitter wrote:
> X-Debbugs-CC: Konrad Podczeck <konrad.podczeck@univie.ac.at>
> This is with our latest build, which is derived from the Emacs 25 branch.
>
> Is it possible that we’re trying to redisplay or scroll after the window was
> removed?
> The stack trace might be actionable in this case, so I’m reporting this here.
I’m inclined to suspect that we’re processing input while the OS is
closing the frame. We got similar crashes when minimizing without
blocking input.
> > 21 org.gnu.Aquamacs 0x0000000100005907 update_frame + 135
> > 22 org.gnu.Aquamacs 0x0000000100029563 redisplay_internal +
> > 6083
> > 23 org.gnu.Aquamacs 0x00000001000ca4af read_char + 1999
^^^^^^^^^
> > 24 org.gnu.Aquamacs 0x00000001000c7bfa read_key_sequence +
> > 1946
> > 25 org.gnu.Aquamacs 0x00000001000c6332 command_loop_1 + 1154
> > 26 org.gnu.Aquamacs 0x0000000100145349
> > internal_condition_case + 265
Unfortunately it looks like input is already blocked when closing the
frame (nsterm.m:1657), so I’m a little at a loss.
(I’m assuming that by ‘after closing a frame’ you mean as soon as you
close it, and not that there’s a pause then the crash?)
Is it possible to recompile with NSTRACE turned on so we can see the
sequence of NS functions up to a crash?
--
Alan Third