Crash force-deleting the only frame

Crash force-deleting the only frame

[Juanma Barranquero]

I'm getting crashes when deleting by force the only frame. It is
repeatable, but I've been unable to find the logic.

Windows port, with GCC 3.4.5 (mingw special):

 C:\> emacs.exe -q --no-site-file

   => M-: (delete-frame (selected-frame) t) [ENTER]

Emacs exits normally (as expected).

 C:\> emacs.exe -q --no-site-file --eval "(progn (sit-for 2)
(delete-frame (selected-frame) t))"

  => Crash dialog and message:

"This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information."

-- 
                    /L/e/k/t/u

Re: Crash force-deleting the only frame

[Eli Zaretskii]

> Date: Tue, 31 Oct 2006 16:33:18 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> 
>  C:\> emacs.exe -q --no-site-file --eval "(progn (sit-for 2)
> (delete-frame (selected-frame) t))"
> 
>   => Crash dialog and message:
> 
> "This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information."

Can you run under a debugger and see where it is crashing?

Re: Crash force-deleting the only frame

[Juanma Barranquero]

On 10/31/06, Eli Zaretskii <eliz@gnu.org> wrote:

> Can you run under a debugger and see where it is crashing?

I can try, but I know exactly nothing about gdb.

-- 
                    /L/e/k/t/u

Re: Crash force-deleting the only frame

[Richard Stallman]

    I'm getting crashes when deleting by force the only frame. It is
    repeatable, but I've been unable to find the logic.

    Windows port, with GCC 3.4.5 (mingw special):

     C:\> emacs.exe -q --no-site-file

       => M-: (delete-frame (selected-frame) t) [ENTER]

It does not fail for me on GNU/Linux.

Re: Crash force-deleting the only frame

[Michael Welsh Duggan]

Richard Stallman <rms@gnu.org> writes:

>     I'm getting crashes when deleting by force the only frame. It is
>     repeatable, but I've been unable to find the logic.
>
>     Windows port, with GCC 3.4.5 (mingw special):
>
>      C:\> emacs.exe -q --no-site-file
>
>        => M-: (delete-frame (selected-frame) t) [ENTER]
>
> It does not fail for me on GNU/Linux.

It does for me.

Current directory is /usr/local/src/emacs/
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -q --no-site-file --eval "(progn (sit-for 2) (delete-frame (selected-frame) t))"
Starting program: /usr/local/bin/emacs -q --no-site-file --eval "(progn (sit-for 2) (delete-frame (selected-frame) t))"
[Thread debugging using libthread_db enabled]
[New Thread -1213809840 (LWP 5792)]

Program received signal SIGABRT, Aborted.
[Switching to Thread -1213809840 (LWP 5792)]
0xb7a9ec51 in kill () from /lib/libc.so.6
(gdb) bt
#0  0xb7a9ec51 in kill () from /lib/libc.so.6
#1  0x0811ef19 in abort () at emacs.c:464
#2  0x080a6284 in window_loop (type=GET_BUFFER_WINDOW, obj=137962820, mini=1, frames=137931001) at window.c:2113
#3  0x080a694b in Fget_buffer_window (buffer=137962820, frame=137931001) at window.c:2363
#4  0x081408c8 in Fset_buffer_modified_p (flag=137930953) at buffer.c:1092
#5  0x081a7927 in Ffuncall (nargs=2, args=0xbfd4b7d0) at eval.c:2997
#6  0x081df242 in Fbyte_code (bytestr=137057075, vector=137057092, maxdepth=96) at bytecode.c:679
#7  0x081a80f6 in funcall_lambda (fun=137057044, nargs=1, arg_vector=0xbfd4baf4) at eval.c:3184
#8  0x081a7bb6 in Ffuncall (nargs=2, args=0xbfd4baf0) at eval.c:3043
#9  0x081df242 in Fbyte_code (bytestr=137048131, vector=137048148, maxdepth=56) at bytecode.c:679
#10 0x081a80f6 in funcall_lambda (fun=137048108, nargs=0, arg_vector=0xbfd4be04) at eval.c:3184
#11 0x081a7bb6 in Ffuncall (nargs=1, args=0xbfd4be00) at eval.c:3043
#12 0x081df242 in Fbyte_code (bytestr=137045051, vector=137045068, maxdepth=48) at bytecode.c:679
#13 0x081a80f6 in funcall_lambda (fun=137045028, nargs=0, arg_vector=0xbfd4c080) at eval.c:3184
#14 0x081a7dd0 in apply_lambda (fun=137045028, args=137930953, eval_flag=1) at eval.c:3108
#15 0x081a6d04 in Feval (form=139733861) at eval.c:2370
#16 0x081226c6 in top_level_2 () at keyboard.c:1335
#17 0x081a554e in internal_condition_case (bfun=0x81226b3 <top_level_2>, handlers=137975657, hfun=0x81222f6 <cmd_error>) at eval.c:1481
#18 0x081226fa in top_level_1 () at keyboard.c:1343
#19 0x081a5009 in internal_catch (tag=137971865, func=0x81226c8 <top_level_1>, arg=137930953) at eval.c:1222
#20 0x08122633 in command_loop () at keyboard.c:1300
#21 0x08122074 in recursive_edit_1 () at keyboard.c:1003
#22 0x081221b6 in Frecursive_edit () at keyboard.c:1064
#23 0x08120a71 in main (argc=5, argv=0xbfd4c8f4) at emacs.c:1794
(gdb) 

-- 
Michael Welsh Duggan
(md5i@cs.cmu.edu)

Re: Crash force-deleting the only frame

[Chong Yidong]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

>> It does not fail for me on GNU/Linux.
>
> It does for me.
>
> (gdb) run -q --no-site-file --eval "(progn (sit-for 2) (delete-frame
>       (selected-frame) t))"

I can reproduce it too.  The sit-for isn't necessary; all you need is

 emacs --eval "(delete-frame (selected-frame) t)"

I'll look into the problem.

Re: Crash force-deleting the only frame

[Juanma Barranquero]

On 11/1/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> The sit-for isn't necessary;

I know. I added it to be sure the frame was fully created and
displayed before trying to delete it.

> I'll look into the problem.

Thanks.

                    /L/e/k/t/u

Re: Crash force-deleting the only frame

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/1/06, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> The sit-for isn't necessary;
>>
>> emacs --eval "(delete-frame (selected-frame) t)"
>
> I know. I added it to be sure the frame was fully created and
> displayed before trying to delete it.

Okay, I looked at this, and now I'm not sure there's any bug.  If you
specify an --eval command-line arg that deletes the only frame, what
else could Emacs possibly do other than abort execution?  "Fatal error
(6)Aborted" is an abort; it's not really a crash.

Re: Crash force-deleting the only frame

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Okay, I looked at this, and now I'm not sure there's any bug.  If you
> specify an --eval command-line arg that deletes the only frame, what
> else could Emacs possibly do other than abort execution?

IMHO there are two options:

- refuse to delete the frame despite FORCE,
- exit gracefully.

> "Fatal error (6)Aborted" is an abort; it's not really a crash.

An abort is still a crash (and you'll get a core dump when enabled).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Crash force-deleting the only frame

[Chong Yidong]

Andreas Schwab <schwab@suse.de> writes:

>> Okay, I looked at this, and now I'm not sure there's any bug.  If you
>> specify an --eval command-line arg that deletes the only frame, what
>> else could Emacs possibly do other than abort execution?
>
> IMHO there are two options:
>
> - refuse to delete the frame despite FORCE,
> - exit gracefully.

The latter is not difficult to arrange:

*** emacs/lisp/startup.el.~1.419.~	2006-09-26 13:10:39.000000000 -0400
--- emacs/lisp/startup.el	2006-11-01 17:55:11.000000000 -0500
***************
*** 1877,1883 ****
                           (setq line 0)
                           (unless (< column 1)
                             (move-to-column (1- column)))
!                          (setq column 0))))))))
  
        ;; If 3 or more files visited, and not all visible,
        ;; show user what they all are.  But leave the last one current.
--- 1877,1884 ----
                           (setq line 0)
                           (unless (< column 1)
                             (move-to-column (1- column)))
!                          (setq column 0))))))
! 	  (unless (frame-live-p (selected-frame)) (kill-emacs nil))))
  
        ;; If 3 or more files visited, and not all visible,
        ;; show user what they all are.  But leave the last one current.

Re: Crash force-deleting the only frame

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>>> Okay, I looked at this, and now I'm not sure there's any bug.  If you
>>> specify an --eval command-line arg that deletes the only frame, what
>>> else could Emacs possibly do other than abort execution?
>>
>> IMHO there are two options:
>>
>> - refuse to delete the frame despite FORCE,
>> - exit gracefully.

3: stay around in case gnuclient will open another window.  But I
don't think that emacsclient has this functionality, and we'd probably
need the multi-tty branch.

> The latter is not difficult to arrange:
>
> *** emacs/lisp/startup.el.~1.419.~	2006-09-26 13:10:39.000000000 -0400
> --- emacs/lisp/startup.el	2006-11-01 17:55:11.000000000 -0500
> ***************
> *** 1877,1883 ****
>                            (setq line 0)
>                            (unless (< column 1)
>                              (move-to-column (1- column)))
> !                          (setq column 0))))))))
>   
>         ;; If 3 or more files visited, and not all visible,
>         ;; show user what they all are.  But leave the last one current.
> --- 1877,1884 ----
>                            (setq line 0)
>                            (unless (< column 1)
>                              (move-to-column (1- column)))
> !                          (setq column 0))))))
> ! 	  (unless (frame-live-p (selected-frame)) (kill-emacs nil))))

Does this not do to much when we delete the last frame on the current
display/terminal, but there are still frames on other displays?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Crash force-deleting the only frame

[Chong Yidong]

David Kastrup <dak@gnu.org> writes:

>> *** emacs/lisp/startup.el.~1.419.~	2006-09-26 13:10:39.000000000 -0400
>> --- emacs/lisp/startup.el	2006-11-01 17:55:11.000000000 -0500
>> ***************
>> *** 1877,1883 ****
>>                            (setq line 0)
>>                            (unless (< column 1)
>>                              (move-to-column (1- column)))
>> !                          (setq column 0))))))))
>>   
>>         ;; If 3 or more files visited, and not all visible,
>>         ;; show user what they all are.  But leave the last one current.
>> --- 1877,1884 ----
>>                            (setq line 0)
>>                            (unless (< column 1)
>>                              (move-to-column (1- column)))
>> !                          (setq column 0))))))
>> ! 	  (unless (frame-live-p (selected-frame)) (kill-emacs nil))))
>
> Does this not do to much when we delete the last frame on the current
> display/terminal, but there are still frames on other displays?

I think there is no need to kill Emacs in that situation.  The above
code is based on similar code in command_loop_1,

      if (! FRAME_LIVE_P (XFRAME (selected_frame)))
	Fkill_emacs (Qnil);

which is how Emacs exits cleanly when you do "M-: (delete-frame nil t)"

Re: Crash force-deleting the only frame

[Lennart Borgman]

Chong Yidong wrote:
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>   
>> On 11/1/06, Chong Yidong <cyd@stupidchicken.com> wrote:
>>
>>     
>>> The sit-for isn't necessary;
>>>
>>> emacs --eval "(delete-frame (selected-frame) t)"
>>>       
>> I know. I added it to be sure the frame was fully created and
>> displayed before trying to delete it.
>>     
>
> Okay, I looked at this, and now I'm not sure there's any bug.  If you
> specify an --eval command-line arg that deletes the only frame, what
> else could Emacs possibly do other than abort execution?  "Fatal error
> (6)Aborted" is an abort; it's not really a crash.
>   

It could behave the same way it does as when you execute this code in 
the scratch buffer (after just starting with emacs -Q).

Re: Crash force-deleting the only frame

[Juanma Barranquero]

On 11/1/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> Okay, I looked at this, and now I'm not sure there's any bug.  If you
> specify an --eval command-line arg that deletes the only frame, what
> else could Emacs possibly do other than abort execution?  "Fatal error
> (6)Aborted" is an abort; it's not really a crash.

There are two behaviors: in one, killing the only frame exits Emacs.
The other one produces an abort.

For example, with a one-line .emacs.el containing just

 (ido-mode)

I get a crash with "M-: (delete-frame nil t)" when there's a .ido.last
file, a normal exit where there is none.

So, something's happening.

                    /L/e/k/t/u

Re: Crash force-deleting the only frame

[Richard Stallman]

    Okay, I looked at this, and now I'm not sure there's any bug.  If you
    specify an --eval command-line arg that deletes the only frame, what
    else could Emacs possibly do other than abort execution?  "Fatal error
    (6)Aborted" is an abort; it's not really a crash.

It could call Fkill_emacs.  That would be the clean way to terminate.