emacs-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]