[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25119: Acknowledgement (Hard freeze when switching to indirect buffe
From: |
Ryan Johnson |
Subject: |
bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer) |
Date: |
Mon, 5 Dec 2016 10:37:02 -0700 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
Apologies, it looks like I was debugging the wrong emacs instance in my
initial report.
The correct output of gdb `bt full` is attached.
(gdb) xbacktrace
"read-key-sequence-vector" (0x57f89050)
0x4872440 PVEC_COMPILED
"funcall" (0x57f89190)
"read-key" (0x57f89498)
"read-char-choice" (0x57f89600)
"ask-user-about-supersession-threat" (0x57f897b8)
"put-text-property" (0x57f8bae8)
"jit-lock-fontify-now" (0x57f8bc78)
"jit-lock-function" (0x57f8be38)
"redisplay_internal (C function)" (0xb856a8)
This time, sending SIGUSR2 worked (sort of), and produced:
Debugger entered--beginning evaluation of function call form:
* (funcall #[0 "\302\301!\210\303\300!\207" [(keymap #^[nil nil keymap
#^^[3 0 set-mark-command move-beginning-of-line backward-char
mode-specific-command-prefix delete-c$
#^^[3 0 set-mark-command move-beginning-of-line backward-char
mode-specific-command-prefix delete-c$
read-key(#("AlphaTree.cpp changed on disk; really edit the buffer?
(y, n, r or C-h) " 0 72 (face $
read-char-choice("AlphaTree.cpp changed on disk; really edit the
buffer? (y, n, r or C-h) " (121 $
ask-user-about-supersession-threat("/home/ryan/projects/lb-alpha-tree/BloxData/blox/alg/alpha/Alp$
put-text-property(2077 2599 fontified t)
jit-lock-fontify-now(2080 2580)
jit-lock-function(2080)
redisplay_internal\ \(C\ function\)()
Unfortunately, the lisp debugger window seems to have line truncation
enabled. Emacs is not responsive after that, reporting a timer error and
complaining afterward that it doesn't recognize any keystrokes:
Error running timer: (no-catch read-key [24])
a is undefined
C-c is undefined
M-x is undefined
Hitting `q` does trigger the response "Back to top level." ... but then
emacs hangs again, until I re-send SIGUSR2.
The hang usually occurs when I switch to an indirect buffer I've not
used in a while (overnight, in this case), and on a shared machine where
people often run memory-intensive workloads. The backtrace above
suggests that the file has been modified outside emacs in the meantime,
which is probably true, since I frequently use patch queues.
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. I will admit I
never tried typing "y" or "n" in response to the hang... I'll be sure to
try that next time.
Regards,
Ryan
emacs-backtrace.txt.gz
Description: GNU Zip compressed data