bug#9006: 24.0.50; Abort in unshow_buffer/kill-buffer

[Stephen Berman <stephen.berman@gmx.net>]

On Thu, 07 Jul 2011 10:23:51 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> The Lisp backtrace shows vertical-motion being called just before
>> kill-buffer, which makes Emacs abort.
>
> I see.
>
>> I induced the abort again, under the same conditions as described above,
>> and got exactly the same backtrace.  I'll leave the process running for
>> a few hours before I have to shut down the machine, in case anyone can
>> offer debugging suggestions.
>
> But did you observe the same sluggishness again this time and did you do
> the same things (delete text, type C-g)?  How old was your Emacs session
> this time?

This time I wasn't editing but just moving around the buffer rapidly,
holding down keys like C-n, C-p, C-f, C-v etc. until Emacs didn't
respond anymore, then C-g, upon which Emacs aborted.  The session was
not quite as old as the previous one, 9-10 hours.  I had tried
unsuccessfully to induce the crash several times earlier in the session.
One thing that may play a role is that, when this induced abort
occurred, the machine was running another program that was consuming a
large amount of CPU cycles, which made Emacs (even more) sluggish
(though when the crash that prompted my OP occurred I wasn't running
that other program, yet Emacs was sluggish anyway).  And indeed, I was
just able to induce the abort again with the same procedure: while
another CPU-intensive program was running, I moved point with C-n
etc. rapidly around in a Gnus buffer, until there was no response, hit
C-g (this time 3 times in succession; I can't remember if that was the
case with the other crashes), and Emacs aborted, with the same
backtrace.  This time the session was 2-3 hours old.  I then immediately
tried to induce the crash again with a fresh session under otherwise
identical conditions, but so far it hasn't crashed.  If I do get another
crash, I'll leave the process running again.

Steve Berman