abort in `make-frame'

abort in `make-frame'

[Luc Teirlinck]

If one specifies one of the `icon-left' or `icon-top' frame
parameters, both need to be specified.  This is not documented in the
Elisp manual.  That is no problem, I will document it.  What is a
problem is that inadvertently forgetting to do so makes Emacs abort.

I did:

[bash2.05b.0 ~ 3 1] cd /home/teirllm/emacscvsdir/emacs/src
[bash2.05b.0 ~/emacscvsdir/emacs/src 3 2] gdb emacs-21.3.50.1

(gdb) run -q --eval '(blink-cursor-mode 0)'
Starting program: /home/teirllm/emacscvsdir/emacs/src/emacs-21.3.50.1
-q --eval '(blink-cursor-mode 0)'

Then:

M-: (make-frame '((icon-left . 0)))

Result:

    Debugger entered--Lisp error: (error "Both left and top icon corners
    of icon must be specified")
      x-create-frame(((visibility) (icon-left . 0)))
      x-create-frame-with-faces(((icon-left . 0)))
      make-frame(((icon-left . 0)))
      eval((make-frame (quote (...))))
      eval-expression((make-frame (quote (...))) nil)
      call-interactively(eval-expression)

Now, this is expected.

What I did not expect is that quitting out of the debugger with `q'
would make Emacs abort.  Is this unavoidable?

Below are an xbacktrace and a backtrace.

Breakpoint 1, abort () at emacs.c:428
428	     kill (getpid (), SIGABRT);
(gdb) xbacktrace
"top-level"
"call-interactively"
"recursive-edit"
"byte-code"
"debug"
"x-create-frame"
"x-create-frame-with-faces"
"make-frame"
"eval"
"eval-expression"
"call-interactively"
(gdb) bt
#0  abort () at emacs.c:428
#1  0x0817e8b8 in EmacsFrameDestroy (widget=0x865daa0) at widget.c:761
#2  0x40095cfe in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#3  0x40095afc in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#4  0x40095aa3 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#5  0x40095aa3 in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#6  0x4009604a in _XtCreateHookObj () from /usr/X11R6/lib/libXt.so.6
#7  0x4009614a in _XtDoPhase2Destroy () from /usr/X11R6/lib/libXt.so.6
#8  0x40096340 in XtDestroyWidget () from /usr/X11R6/lib/libXt.so.6
#9  0x080c7f03 in x_free_frame_resources (f=0x8667428) at xterm.c:9017
#10 0x080ce075 in unwind_create_frame (frame=140932140) at xfns.c:2810
#11 0x0813facf in unbind_to (count=2, value=138193841) at eval.c:3084
#12 0x0813d288 in unwind_to_catch (catch=0xbffff430, value=138193841)
    at eval.c:1139
#13 0x0813d31a in Fthrow (tag=138248793, value=138193841) at
eval.c:1173
#14 0x080e4c89 in Ftop_level () at keyboard.c:1345
#15 0x0813f10e in Ffuncall (nargs=1, args=0xbfffdf40) at eval.c:2722
#16 0x0813bb89 in Fcall_interactively (function=138248793, 
    record_flag=17274230, keys=140390028) at callint.c:862
#17 0x080ef8b5 in Fcommand_execute (cmd=138248793,
record_flag=138193841, 
    keys=138193841, special=138193841) at keyboard.c:9724
#18 0x080e5beb in command_loop_1 () at keyboard.c:1776
#19 0x0813d686 in internal_condition_case (bfun=0x80e4d18
<command_loop_1>, 
    handlers=138254769, hfun=0x80e4894 <cmd_error>) at eval.c:1335
#20 0x080e4b8a in command_loop_2 () at keyboard.c:1306
#21 0x0813d21f in internal_catch (tag=138278241, 
    func=0x80e4b6c <command_loop_2>, arg=138193841) at eval.c:1096
#22 0x080e4b5b in command_loop () at keyboard.c:1273
#23 0x080e464b in recursive_edit_1 () at keyboard.c:978
#24 0x080e4773 in Frecursive_edit () at keyboard.c:1039
#25 0x0813f10e in Ffuncall (nargs=1, args=0xbfffe480) at eval.c:2722
#26 0x08165888 in Fbyte_code (bytestr=138651827, vector=140397868,
maxdepth=24)
    at bytecode.c:689
#27 0x0813e76a in Feval (form=139727429) at eval.c:2086
#28 0x0813c25b in Fprogn (args=139726933) at eval.c:408
#29 0x08094e4b in Fsave_window_excursion (args=139726933) at
window.c:5932
#30 0x08165cfd in Fbyte_code (bytestr=138201363, vector=140283404, 
    maxdepth=208) at bytecode.c:838
#31 0x0813f63f in funcall_lambda (fun=140704588, nargs=2, 
    arg_vector=0xbfffe794) at eval.c:2912
#32 0x0813f215 in Ffuncall (nargs=3, args=0xbfffe790) at eval.c:2782
#33 0x0813eac8 in Fapply (nargs=2, args=0xbfffe820) at eval.c:2230
#34 0x0813ee33 in apply1 (fn=138425417, arg=139822133) at eval.c:2486
#35 0x0813c043 in call_debugger (arg=139822133) at eval.c:265
#36 0x0813ddac in find_handler_clause (handlers=138254769, 
    conditions=138226581, sig=138254769, data=139822173, 
    debugger_value_ptr=0xbfffe8c8) at eval.c:1678
#37 0x0813d9f3 in Fsignal (error_symbol=138254769, data=139822173)
    at eval.c:1509
#38 0x0813dfa8 in error (
    m=0x818b400 "Both left and top icon corners of icon must be
specified", 
    a1=0x0, a2=0x86189e8 "", 
    a3=0x855155d
"$U\b|K\\\b\261\253<\bu\025U\b\261\253<\b\311GB\b\275\025U\b+nG\bM\025U\b9\231=\b\265\025U\b\001|=\b}\025U\b\231\354T\b\215\255B\bKnG\b\225\025U\bI\357>\b\235\025U\b\335\034U\b}\022U\bm%U\b\261\253<\b\205\025U\b\375\025U\b\241\252A\b\315\034U\b=\026U\b\261\253<\b\365\025U\b\261\253<\b\345\025U\b\261\253<\b9\231=\b\355\025U\b\251P>\b\261\253<\b1\322=\b\335\025U\b\261\253<\b\261\253<\b%\026U\b\325\025U\b\025\026U\b\261\253<\b9\231=\b\035\026U\b\251P>\b\261\253<\b\031\322=\b\r"...)
at eval.c:1762
#39 0x080cdc69 in x_icon (f=0x8667428, parms=139793757) at xfns.c:2658
#40 0x080ceb5f in Fx_create_frame (parms=139793757) at xfns.c:3127
#41 0x0813f123 in Ffuncall (nargs=2, args=0xbfffeb48) at eval.c:2725
#42 0x08165888 in Fbyte_code (bytestr=136236899, vector=136236980,
maxdepth=40)
---Type <return> to continue, or q <return> to quit---
    at bytecode.c:689
#43 0x0813f63f in funcall_lambda (fun=136236852, nargs=1, 
    arg_vector=0xbfffec74) at eval.c:2912
#44 0x0813f215 in Ffuncall (nargs=2, args=0xbfffec70) at eval.c:2782
#45 0x08165888 in Fbyte_code (bytestr=136614451, vector=136614492,
maxdepth=24)
    at bytecode.c:689
#46 0x0813f63f in funcall_lambda (fun=136614404, nargs=1, 
    arg_vector=0xbfffed30) at eval.c:2912
#47 0x0813f352 in apply_lambda (fun=136614404, args=139797397,
eval_flag=1)
    at eval.c:2834
#48 0x0813e8a7 in Feval (form=139797869) at eval.c:2138
#49 0x0813f123 in Ffuncall (nargs=2, args=0xbfffeed0) at eval.c:2725
#50 0x08165888 in Fbyte_code (bytestr=136367779, vector=136367884,
maxdepth=40)
    at bytecode.c:689
#51 0x0813f63f in funcall_lambda (fun=136367724, nargs=2, 
    arg_vector=0xbffff004) at eval.c:2912
#52 0x0813f215 in Ffuncall (nargs=3, args=0xbffff000) at eval.c:2782
#53 0x0813eac8 in Fapply (nargs=2, args=0xbffff090) at eval.c:2230
#54 0x0813ee33 in apply1 (fn=138561481, arg=139793973) at eval.c:2486
#55 0x0813ac65 in Fcall_interactively (function=138561481, 
    record_flag=138193841, keys=138250700) at callint.c:406
#56 0x080ef8b5 in Fcommand_execute (cmd=138561481,
record_flag=138193841, 
    keys=138193841, special=138193841) at keyboard.c:9724
#57 0x080e5beb in command_loop_1 () at keyboard.c:1776
#58 0x0813d686 in internal_condition_case (bfun=0x80e4d18
<command_loop_1>, 
    handlers=138254769, hfun=0x80e4894 <cmd_error>) at eval.c:1335
#59 0x080e4b8a in command_loop_2 () at keyboard.c:1306
#60 0x0813d21f in internal_catch (tag=138248793, 
    func=0x80e4b6c <command_loop_2>, arg=138193841) at eval.c:1096
#61 0x080e4b19 in command_loop () at keyboard.c:1285
#62 0x080e464b in recursive_edit_1 () at keyboard.c:978
#63 0x080e4773 in Frecursive_edit () at keyboard.c:1039
#64 0x080e366f in main (argc=4, argv=0xbffff834) at emacs.c:1687
#65 0x40317627 in __libc_start_main (main=0x80e2998 <main>, argc=4, 
    ubp_av=0xbffff834, init=0x804e118 <_init>, fini=0x818421c <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff82c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

Re: abort in `make-frame'

[Jan D.]

Luc Teirlinck wrote:
> If one specifies one of the `icon-left' or `icon-top' frame
> parameters, both need to be specified.  This is not documented in the
> Elisp manual.  That is no problem, I will document it.  What is a
> problem is that inadvertently forgetting to do so makes Emacs abort.
> 

This only happens in a Motif/Lesstif or a Lucid build.  The frame
that is partially created when the error occurs is freed.  The code
that frees the frame expects a complete frame and does some (not
need) checks and aborts if they are not true (normal_gc != 0 in this
case).

I've removed the check, but now it seems like some glyphs are not
freed either, because I now get an abort when doing C-x C-q (in
all X versions of Emacs):

#0  abort () at emacs.c:428
#1  0x08053372 in check_glyph_memory () at dispnew.c:2577
#2  0x0811005d in shut_down_emacs (sig=0, no_x=0, stuff=138640033)
     at emacs.c:2068
#3  0x0810ff3e in Fkill_emacs (arg=138640033) at emacs.c:1968
#4  0x0818e7bf in Ffuncall (nargs=1, args=0xbfffe7d0) at eval.c:2725
#5  0x081c4107 in Fbyte_code (bytestr=136645323, vector=136645444, maxdepth=40)
     at bytecode.c:689
#6  0x0818efa8 in funcall_lambda (fun=136645276, nargs=1,
     arg_vector=0xbfffea34) at eval.c:2912
#7  0x0818e9dc in Ffuncall (nargs=2, args=0xbfffea30) at eval.c:2773
#8  0x0818a5e0 in Fcall_interactively (function=139021041,
     record_flag=138640033, keys=138696892) at callint.c:862
#9  0x081200c8 in Fcommand_execute (cmd=139021041, record_flag=138640033,
     keys=138640033, special=138640033) at keyboard.c:9724
#10 0x08112abc in command_loop_1 () at keyboard.c:1776
#11 0x0818c542 in internal_condition_case (bfun=0x811158e <command_loop_1>,
     handlers=138700961, hfun=0x811109e <cmd_error>) at eval.c:1335
#12 0x081113f5 in command_loop_2 () at keyboard.c:1306
#13 0x0818c015 in internal_catch (tag=138694969,
     func=0x81113d2 <command_loop_2>, arg=138640033) at eval.c:1096
#14 0x081113ab in command_loop () at keyboard.c:1285
#15 0x08110e17 in recursive_edit_1 () at keyboard.c:978
#16 0x08110f5c in Frecursive_edit () at keyboard.c:1039
#17 0x0810f8f1 in main (argc=2, argv=0xbffff414) at emacs.c:1687

(gdb) up
#1  0x08053372 in check_glyph_memory () at dispnew.c:2577
2577        abort ();
(gdb) l
2572      FOR_EACH_FRAME (tail, frame)
2573        free_glyphs (XFRAME (frame));
2574
2575      /* Check that nothing is left allocated.  */
2576      if (glyph_matrix_count)
2577        abort ();
2578      if (glyph_pool_count)
2579        abort ();
2580    }
2581
(gdb) xbacktrace
"kill-emacs"
"save-buffers-kill-emacs"
"call-interactively"


The question is, does it matter if glyph memory is allocated when
Emacs is exiting?  Are there X resources, like GC, pixmaps, etc.
that will leak?  I am not very familiar with this code.

	Jan D.

Re: abort in `make-frame'

[Richard Stallman]

	  x-create-frame(((visibility) (icon-left . 0)))
	  x-create-frame-with-faces(((icon-left . 0)))
	  make-frame(((icon-left . 0)))
	  eval((make-frame (quote (...))))
	  eval-expression((make-frame (quote (...))) nil)
	  call-interactively(eval-expression)

    Now, this is expected.

    What I did not expect is that quitting out of the debugger with `q'
    would make Emacs abort.  Is this unavoidable?

The cause of this is surely that the error is signaled at a time
when the frame is already partly set up.  One needs to debug the
code around that place.  When the actual abort happens, that's too
late to be interesting.

The error is signaled from x_icon, which has not yet done anything
interesting.  But x_icon is called from Fx_create_frame after it
has already created the frame's window.

Does this fix it?

*** xfns.c	14 May 2004 05:26:50 -0400	1.610
--- xfns.c	21 Jul 2004 17:47:42 -0400	
***************
*** 2633,2638 ****
--- 2633,2660 ----
  #endif /* not USE_GTK */
  #endif /* not USE_X_TOOLKIT */
  
+ /* Verify that the icon position args for this window are valid.  */
+ 
+ static void
+ x_icon_verify (f, parms)
+      struct frame *f;
+      Lisp_Object parms;
+ {
+   Lisp_Object icon_x, icon_y;
+ 
+   /* Set the position of the icon.  Note that twm groups all
+      icons in an icon window.  */
+   icon_x = x_frame_get_and_record_arg (f, parms, Qicon_left, 0, 0, RES_TYPE_NUMBER);
+   icon_y = x_frame_get_and_record_arg (f, parms, Qicon_top, 0, 0, RES_TYPE_NUMBER);
+   if (!EQ (icon_x, Qunbound) && !EQ (icon_y, Qunbound))
+     {
+       CHECK_NUMBER (icon_x);
+       CHECK_NUMBER (icon_y);
+     }
+   else if (!EQ (icon_x, Qunbound) || !EQ (icon_y, Qunbound))
+     error ("Both left and top icon corners of icon must be specified");
+ }
+ 
  /* Handle the icon stuff for this window.  Perhaps later we might
     want an x_set_icon_position which can be called interactively as
     well.  */
***************
*** 3116,3121 ****
--- 3138,3145 ----
  
    tem = x_get_arg (dpyinfo, parms, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
    f->no_split = minibuffer_only || EQ (tem, Qt);
+ 
+   x_icon_verify (f, parms);
  
    /* Create the X widget or window.  */
  #ifdef USE_X_TOOLKIT

Re: abort in `make-frame'

[Luc Teirlinck]

Richard  Stallman wrote:

   The error is signaled from x_icon, which has not yet done anything
   interesting.  But x_icon is called from Fx_create_frame after it
   has already created the frame's window.

   Does this fix it?

Yes.  In the meantime, an alternative patch has been checked in:

2004-07-21  Jan Djrv  <jan.h.d@swipnet.se>

	    * widget.c (EmacsFrameDestroy): Don't abort if normal_gc
              is 0.

This also fixes the immediate problem (by simply removing the call to
`abort'),  but if I understood Jan's message correctly, causes some
other problems.  So I guess your patch is superior.  I tested that it
works by reverting to Rev1.70 of widget.c (that is, the one just
before Jan's patch).

Sincerely,

Luc.

Re: abort in `make-frame'

[Jan D.]

> 	    * widget.c (EmacsFrameDestroy): Don't abort if normal_gc
>               is 0.
>
> This also fixes the immediate problem (by simply removing the call to
> `abort'),  but if I understood Jan's message correctly, causes some
> other problems.  So I guess your patch is superior.  I tested that it
> works by reverting to Rev1.70 of widget.c (that is, the one just
> before Jan's patch).

There is no need to revert my change.  There is no reason to abort
just because normal_gc is 0.  x_free_gcs, which EmacsFrameDestroy calls
just after the abort, checks for this also.

	Jan D.

Re: abort in `make-frame'

[Luc Teirlinck]

To avoid confusion, I want to clarify that I reverted to 1.70 and
applied Richard's patch in my personal Emacs version, for testing.
I did not revert or install anything in the Savannah CVS.

Sincerely,

Luc.

Re: abort in `make-frame'

[Richard Stallman]

Could you install my patch for me?

Re: abort in `make-frame'

[Luc Teirlinck]

 Richard Stallman wrote:

   Could you install my patch for me?

Done.

Sincerely,

Luc.