Re: SIGABRT while stress-testing with gnuclient/gnudoit

[Alex Schroeder]

I think I have a test case for this, now.

~% emacs -q

In the scratch-buffer, evaluate (delete-frame (selected-frame) t)
and you will get this:

Fatal error (6).zsh: abort      emacs -q

So part of it is the gnuclient implementation (at least the one I am
using), but the other half is that Emacs aborts...  The FORCE argument
is explained as follows:

    Normally, you may not delete a frame if all other frames are
    invisible, but if the second optional argument FORCE is non-nil,
    you may do so.

I think we should add (and implement): "You may never delete the last
existing frame, however.  Use `kill-emacs' instead."

Alex.


Alex Schroeder <address@hidden> writes:

> This bug report will be sent to the Free Software Foundation,
> not to your local site managers!
> Please write in English, because the Emacs maintainers do not have
> translators to read other languages for them.
>
> Your bug report will be posted to the address@hidden mailing list.
>
> In GNU Emacs 21.2.92.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2002-11-22 on confusibombus
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: C
>   locale-coding-system: nil
>   default-enable-multibyte-characters: t
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
>
> I was trying to write a new server-edit function.  This comes from the
> gnuserv package, an alternative to using emacsclient.  So I called
> gnudoit several times, and I called gnuclient several times on various
> files, and suddenly got a SIGABRT:
>
> Program received signal SIGABRT, Aborted.
> 0x4030b781 in kill () from /lib/libc.so.6
> (gdb) bt
> #0  0x4030b781 in kill () from /lib/libc.so.6
> #1  0x080ce94e in abort () at emacs.c:387
> #2  0x08062aaa in message_with_string (m=0x8174dbe "%s(y or n) ", 
> string=954459916, log=0) at xdisp.c:6054
> #3  0x0812bc9a in Fy_or_n_p (prompt=954459916) at fns.c:2851
> #4  0x08123cda in Ffuncall (nargs=2, args=0xbffff3e4) at eval.c:2659
> #5  0x0814a34c in Fbyte_code (bytestr=956141884, vector=1224197824, 
> maxdepth=6) at bytecode.c:716
> #6  0x08124297 in funcall_lambda (fun=1223704296, nargs=0, 
> arg_vector=0xbffff57c) at eval.c:2851
> #7  0x08123e01 in Ffuncall (nargs=1, args=0xbffff578) at eval.c:2716
> #8  0x0812389f in run_hook_with_args (nargs=1, args=0xbffff578, 
> cond=to_completion) at eval.c:2330
> #9  0x0812371b in Frun_hooks (nargs=1, args=0xbffff608) at eval.c:2198
> #10 0x08123c46 in Ffuncall (nargs=2, args=0xbffff604) at eval.c:2640
> #11 0x08123a27 in call1 (fn=405329060, arg1=405366228) at eval.c:2456
> #12 0x080cfefc in Fkill_emacs (arg=405209180) at emacs.c:1812
> #13 0x080d11f4 in command_loop_1 () at keyboard.c:1369
> #14 0x08122249 in internal_condition_case (bfun=0x80d1090 <command_loop_1>, 
> handlers=405305524, hfun=0x80d0cd4 <cmd_error>) at eval.c:1267
> #15 0x080d0f68 in command_loop_2 () at keyboard.c:1245
> #16 0x08121ddd in internal_catch (tag=405267108, func=0x80d0f44 
> <command_loop_2>, arg=405209180) at eval.c:1030
> #17 0x080d0f17 in command_loop () at keyboard.c:1224
> #18 0x080d0a91 in recursive_edit_1 () at keyboard.c:950
> #19 0x080d0bc0 in Frecursive_edit () at keyboard.c:1006
> #20 0x080cfaef in main (argc=3, argv=0xbffffc54, envp=0xbffffc64) at 
> emacs.c:1547
>
> The new server-edit was going to call find-file, and then raise-frame.
> I am using the ratpoison window manager.  So selected-frame related
> problems sound plausible:
>
> (gdb) up  
> #1  0x080ce94e in abort () at emacs.c:387
> 387       kill (getpid (), SIGABRT);
> (gdb) up
> #2  0x08062aaa in message_with_string (m=0x8174dbe "%s(y or n) ", 
> string=954459916, log=0) at xdisp.c:6054
> 6054          struct frame *f, *sf = SELECTED_FRAME ();
> (gdb) l
> 6049        {
> 6050          /* The frame whose minibuffer we're going to display the 
> message on.
> 6051             It may be larger than the selected frame, so we need
> 6052             to use its buffer, not the selected frame's buffer.  */
> 6053          Lisp_Object mini_window;
> 6054          struct frame *f, *sf = SELECTED_FRAME ();
> 6055
> 6056          /* Get the frame containing the minibuffer
> 6057             that the selected frame is using.  */
> 6058          mini_window = FRAME_MINIBUF_WINDOW (sf);
>
> The file i as using contained a space, its name is 'touch me'.
>
> (gdb) p selected_frame
> $1 = 1213360240
> (gdb) xframe(selected_frame)
> $2 = (struct frame *) 0x8526870
> (gdb) p selected_frame
> $3 = 1213360240
> (gdb) pr
> #<dead frame emacs: touch me 0x8526870\ >
>
> The macro that calls abort:
>
> #define SELECTED_FRAME()                              \
>      ((FRAMEP (selected_frame)                                \
>        && FRAME_LIVE_P (XFRAME (selected_frame)))     \
>       ? XFRAME (selected_frame)                               \
>       : (abort (), (struct frame *) 0))
>
> It seems that the frame is no longer live -- but i cannot say why.
>
> Recent input:
> C-c n <escape> x r e p o r t - e m a c s <tab> <re
> turn>
>
> Recent messages:
> Reading active file from archive via nnfolder...
> Opening nnfolder server on archive...done
> Reading active file from archive via nnfolder...done
> No new newsgroups
> Checking new news...
> Opening nntp server on news.gnus.org...done
> Opening nndoc server on /home/alex/mbox...done
> Checking new news...done
> Loading gnus-topic...done
> Loading emacsbug...done