bug#25119: Acknowledgement (Hard freeze when switching to indirect buffer)

[Ryan Johnson <scovich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

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

[-- Attachment #2: emacs-backtrace.txt.gz --]
[-- Type: application/x-gzip, Size: 22980 bytes --]