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

[martin rudalics]

> ...with w->buffer the display is unstable, and calling `about-emacs' made
> Emacs abort in unshow_buffer again, but with a different backtrace
> (included below).

It seems to hit the same abort, though.

> I then replaced w->buffer with current_buffer and
> rebuilt, and that was even worse: Emacs aborted before the startup was
> complete; this time the backtrace was the same as in the earlier
> aborts.

Yes that was a silly idea.  My bad.

> Then I tried with old_buffer, and so far, this is working:
> display is normal, about-emacs works, navigating and editing in Gnus
> works (so far); I'm even running a CPU-intensive program simultaneously
> as a stress test.  No abort yet; I'll keep you posted.

That's strange but after all the same bug should hit again when we do

  if (BUFFERP (old_buffer))
    w->buffer = old_buffer;

in `vertical-motion' without restoring w->pointm.  Apparently someone
decided that doing a thing like

"w->buffer = ..."

without further caution is a crime.  So we'd at least have to save the
window point of old_buffer together with old_buffer and restore it when
we restore the old buffer.  All this is completely fragile because I
don't have the slightest idea what `vertical-motion' is allowed to do in
between and how it is interrupted by C-g.

martin