[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25119: Acknowledgement (Hard freeze when switching to indirect buffe
bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)
Mon, 5 Dec 2016 13:14:59 -0700
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
On 12/5/2016 11:44 AM, Eli Zaretskii wrote:
"redisplay_internal (C function)" (0xb856a8)
This looks like Emacs asking you whether to steal the lock from
another Emacs session that is editing the same file.
The message from the lisp backtrace was:
AlphaTree.cpp changed on disk; really edit the buffer? (y, n, r or C-h)
I'm pretty sure the lock-stealing message is rather different from that,
mentioning the PID of the other emacs... but I don't remember off the
top of my head because I very rarely point two emacsen at the same file.
Just a wild speculation, based on the fact that it was apparently stuck
waiting for input while still trying to redraw the screen. Even in a
single thread, signals might allow a self-deadlock of some kind. Or it
could be something else entirely.
I start to suspect that there's some sort of race here, where switching
to the buffer is slow (perhaps due to page faults) and a different
thread tries to process subsequent keystrokes, which triggers the "$FILE
changed on disk; really edit the buffer?" message while the mini-buffer
is still tied up with the "switching to..." message.
What other thread did you have in mind? Emacs does all this in a
Will build it and switch over; I don't think it's available for Ubuntu
Also, perhaps you could try a newer version of Emacs (25.1), maybe
this problem is already fixed there.