Re: Debugging emacs memory management

[Eli Zaretskii]

> From: Dima Kogan <address@hidden>
> Cc: address@hidden, address@hidden
> 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?