bug#1450: w32_reset_fringes

[Stephen Berman]

On Sat, 29 Nov 2008 12:43:21 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> A further datapoint: both the above as well as (setq default-frame-alist
>> '((minibuffer))) also induce a crash in GNU Emacs 23.0.60.16
>> (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 2008-11-20 on escher
>
> I attached a fairly secure and minimally invasive patch.
> Could you try it?

I tried your patch after updating from the current CVS HEAD.  Now
starting with emacs -q --eval "(setq default-frame-alist
'((minibuffer)))" and trying to delete the minibuffer frame via the
window manager does not crash Emacs, but instead results in no deleted
frame and the error message "Attempt to delete a surrogate minibuffer
frame" (from handle-delete-frame).  Likewise, C-x 5 0 from the
minibuffer frame does not delete it, again showing the error message
(now from call-interactively).  With a non-minibuffer frame deletion via
either the window manager or C-x 5 0 succeeds; then as soon as I click
in the minibuffer frame, a new regular frame is created.

As for starting with emacs -q and the evalling (delete-frame nil t),
this also does not make Emacs crash, but raises the error "Attempt to
delete the only frame".  However, I apparently was mistaken in my post
cited above: I thought evalling (delete-frame nil t) produced a core
dump, like the attempt to delete the minibuffer frame did, but I cannot
reproduce that with the unpatched Emacs, so I must have been confused
about the source of the core file (which I since deleted).  Instead,
evalling (delete-frame nil t) in the unpatched Emacs simply kills Emacs,
verified under gdb ("Program exited normally.").  Sorry for misreporting
this yesterday.

Steve Berman