From: Eli Zaretskii <eliz@gnu.org>
To: Dima Kogan <lists@dima.secretsauce.net>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: Debugging emacs memory management
Date: Mon, 05 Oct 2015 10:55:17 +0300 [thread overview]
Message-ID: <83wpv1zr4q.fsf@gnu.org> (raw)
In-Reply-To: <87fv1p232b.fsf@secretsauce.net>
> From: Dima Kogan <lists@dima.secretsauce.net>
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Mon, 05 Oct 2015 00:21:32 -0700
>
> > I tried to reproduce this on my machine, but couldn't. What I see is
> > that the chain of calls you reported happens only once, when the first
> > frame is created. When I later create a second frame, either with
> > "C-x 5 f" or by invoking emacsclient, x_new_font is indeed invoked
> > again, but it doesn't call Fset_char_table_range, and consequently no
> > additional sub-char-tables are allocated.
>
> Hi. This is happening for me again. And I can't make it NOT happen now,
> so I can't compare the two cases. You said you see x_new_font() calls,
> but not the subsequent Fset_char_table_range() calls. I see these
> Fset_char_table_range() calls with every new frame, and I don't know
> where my emacs gets off track. The full backtrace looks like this:
>
>
> (gdb) bt full
> #0 0x00000000005cbdd5 in xmalloc (size=4096) at alloc.c:707
> val = 0x2
> #1 0x00000000005ce184 in allocate_vector_block () at alloc.c:2836
> block = 0x33f7ee0
> #2 0x00000000005ce3a2 in allocate_vector_from_block (nbytes=1040) at alloc.c:2900
> vector = 0x304b568
> block = 0x5cbd0d <mmap_lisp_allowed_p+9>
> index = 510
> restbytes = 140727746112864
> #3 0x00000000005ce9e0 in allocate_vectorlike (len=129) at alloc.c:3108
> nbytes = 1040
> p = 0x5ce34e <allocate_vector_from_block+364>
> #4 0x00000000005ceaed in allocate_vector (len=129) at alloc.c:3148
> v = 0x5cea61 <allocate_vectorlike+245>
> nbytes_max = 9223372036854775807
> #5 0x000000000054e894 in make_uninit_vector (size=129) at lisp.h:3559
> v = 54491861
> p = 0x110
> #6 0x000000000054e8e0 in make_uninit_sub_char_table (depth=3, min_char=64256) at lisp.h:3570
> slots = 129
> v = 60184035045
> #7 0x00000000004ee43b in make_sub_char_table (depth=3, min_char=64256, defalt=0) at chartab.c:141
> i = 0
> table = 0
> #8 0x00000000004ef69a in sub_char_table_set_range (table=54492901, from=64256, to=64262, val=50415725, is_uniprop=false) at chartab.c:473
> sub = 0
> tbl = 0x33f7ee0
> depth = 2
> min_char = 61440
> chars_in_block = 128
> i = 22
> c = 64256
> lim = 32
> #9 0x00000000004ef6d4 in sub_char_table_set_range (table=14575333, from=64256, to=64262, val=50415725, is_uniprop=false) at chartab.c:477
> sub = 54492901
> tbl = 0xde66e0
> depth = 1
> min_char = 0
> chars_in_block = 4096
> i = 15
> c = 61440
> lim = 16
> #10 0x00000000004ef86c in char_table_set_range (table=52981493, from=64256, to=64262, val=50415725) at chartab.c:511
> sub = 14575333
> is_uniprop = false
> lim = 0
> i = 0
> c = 0
> tbl = 0x3286ef0
> #11 0x00000000004efeca in Fset_char_table_range (char_table=52981493, range=17504803, value=50415725) at chartab.c:654
> #12 0x0000000000680b3f in Fset_fontset_font (name=17419252, target=29952, font_spec=15236741, frame=13456677, add=0) at fontset.c:1590
> fontset = 52981493
> font_def = 15103109
> registry = 17878196
> family = 0
> range_list = 17504787
> charset = 0x0
> fontname = 17878292
> ascii_changed = true
> #13 0x0000000000681569 in fontset_from_font (font_object=50891429) at fontset.c:1757
> target = 29952
> font_name = 17419444
> font_spec = 15236741
> registry = 28656
> fontset_spec = 15395877
> alias = 17419220
> name = 17419252
> fontset = 52981493
> val = 0
The difference starts in this frame #13, inside fontset_from_font. On
my system, this call returns where indicated below:
int
fontset_from_font (Lisp_Object font_object)
{
Lisp_Object font_name = font_get_name (font_object);
Lisp_Object font_spec = copy_font_spec (font_object);
Lisp_Object registry = AREF (font_spec, FONT_REGISTRY_INDEX);
Lisp_Object fontset_spec, alias, name, fontset;
Lisp_Object val;
val = assoc_no_quit (font_spec, auto_fontset_alist);
if (CONSP (val))
return XINT (FONTSET_ID (XCDR (val))); <<<<<<<<<<<<<<<<<
Evidently, on your system the call to assoc_no_quit doesn't return a
cons cell, but something else, probably Qnil. Is that true?
If so, please show the values of the 2 arguments to assoc_no_quit (in
their Lisp form, as displayed by the "pp" command).
Also, do you see the same call chain, with _exactly_ the same
arguments, starting from fontset_from_font, each time you create a new
frame?
Finally, please give the exact sequence of commands you invoke to
create a new frame, and what file/buffer is initially displayed in the
new frame. (I used src/xdisp.c via "C-x 5 f".) I'd like to make sure
we ask Emacs to do exactly the same job.
> The lisp object arguments of interest are:
>
> x_new_font:
> font_object = #<font-object "-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1">
>
> Fset_fontset_font:
> name = "-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-fontset-auto129"
> target = latin
> font_spec = #<font-spec nil nil nil nil iso10646-1 nil nil nil nil nil nil nil nil>
>
> here I get find_font_encoding() returning encoding = (unicode-bmp).
> CHARSET_SYMBOL_ID() then converts this encoding to 144
>
> Fset_char_table_range:
> char_table = <long messy thing; in attachment>
> range = (64256 . 64262)
> value = [[#<font-spec nil nil nil nil iso10646-1 nil nil nil nil nil nil nil nil> 144 nil]]
For the record, the range (64256 . 64262) covers the Latin ligatures,
like ff. DejaVu Sans Mono covers only 2 of them. On my system, the
default is Courier New, which supports more. Not sure this has
anything to do with the problem, but just in case, can you start Emacs
with a Courier font, and see if the problem still happens?
next prev parent reply other threads:[~2015-10-05 7:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 6:01 Debugging emacs memory management Dima Kogan
2015-02-11 15:05 ` Stefan Monnier
2015-02-15 20:28 ` Dima Kogan
2015-02-15 20:47 ` Eli Zaretskii
2015-02-16 1:39 ` Stefan Monnier
2015-02-17 7:59 ` Dima Kogan
2015-02-17 15:59 ` Eli Zaretskii
2015-02-18 0:07 ` Stefan Monnier
2015-02-11 19:07 ` Florian Weimer
2015-09-15 19:27 ` Dima Kogan
2015-09-16 16:28 ` Paul Eggert
2015-09-20 22:01 ` Dima Kogan
2015-09-21 6:46 ` Eli Zaretskii
2015-09-21 8:54 ` Dima Kogan
2015-09-21 10:00 ` Eli Zaretskii
2015-09-21 10:21 ` Eli Zaretskii
2015-09-22 21:33 ` Dima Kogan
2015-09-23 6:35 ` Eli Zaretskii
2015-09-23 6:37 ` Dima Kogan
2015-09-23 7:16 ` Eli Zaretskii
2015-10-05 7:21 ` Dima Kogan
2015-10-05 7:55 ` Eli Zaretskii [this message]
2015-10-05 8:24 ` Dima Kogan
2015-10-05 8:33 ` Eli Zaretskii
2015-10-05 8:43 ` Eli Zaretskii
2015-10-05 9:24 ` Dima Kogan
2015-10-05 9:49 ` Dima Kogan
2015-10-05 9:58 ` Andreas Schwab
2015-10-05 10:02 ` Dima Kogan
2015-10-05 10:47 ` Eli Zaretskii
2015-10-05 18:19 ` Dima Kogan
2015-10-05 18:24 ` Eli Zaretskii
2015-10-05 23:21 ` Dima Kogan
2015-10-06 2:41 ` Eli Zaretskii
2015-10-08 21:51 ` Dima Kogan
2015-09-16 16:34 ` Davis Herring
2015-09-16 22:03 ` Markus Triska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83wpv1zr4q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=lists@dima.secretsauce.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.