[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: abort in `make-frame'
From: |
Jan D. |
Subject: |
Re: abort in `make-frame' |
Date: |
Wed, 21 Jul 2004 21:27:01 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 |
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.