From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Debugging emacs memory management Date: Mon, 05 Oct 2015 10:55:17 +0300 Message-ID: <83wpv1zr4q.fsf@gnu.org> References: <87zj8l3r32.fsf@secretsauce.net> <87vbbbxz2e.fsf@secretsauce.net> <55F998C8.4080203@cs.ucla.edu> <87vbb492ea.fsf@secretsauce.net> <83twqonub8.fsf@gnu.org> <87oagw885o.fsf@secretsauce.net> <837fnknlbm.fsf@gnu.org> <834mionkdg.fsf@gnu.org> <87fv1p232b.fsf@secretsauce.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1444032678 22471 80.91.229.3 (5 Oct 2015 08:11:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 08:11:18 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Dima Kogan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 05 10:10:59 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zj0rK-0000Ha-S9 for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 10:10:59 +0200 Original-Received: from localhost ([::1]:44739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj0rK-0004Bj-71 for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 04:10:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj0cQ-0001T9-Jn for emacs-devel@gnu.org; Mon, 05 Oct 2015 03:55:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zj0cD-0007Cq-3R for emacs-devel@gnu.org; Mon, 05 Oct 2015 03:55:25 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:54598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zj0cC-00079v-MJ for emacs-devel@gnu.org; Mon, 05 Oct 2015 03:55:21 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NVQ00J00LBWQN00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Mon, 05 Oct 2015 10:55:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVQ00JE3M06NDA0@a-mtaout21.012.net.il>; Mon, 05 Oct 2015 10:55:19 +0300 (IDT) In-reply-to: <87fv1p232b.fsf@secretsauce.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190925 Archived-At: > From: Dima Kogan > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Mon, 05 Oct 2015 00:21:32 -0700 >=20 > > I tried to reproduce this on my machine, but couldn't. What I se= e 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 wit= h > > "C-x 5 f" or by invoking emacsclient, x_new_font is indeed invoke= d > > again, but it doesn't call Fset_char_table_range, and consequentl= y no > > additional sub-char-tables are allocated. >=20 > 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() cal= ls, > 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 kno= w > where my emacs gets off track. The full backtrace looks like this: >=20 >=20 > (gdb) bt full > #0 0x00000000005cbdd5 in xmalloc (size=3D4096) at alloc.c:707 > val =3D 0x2 > #1 0x00000000005ce184 in allocate_vector_block () at alloc.c:2836 > block =3D 0x33f7ee0 > #2 0x00000000005ce3a2 in allocate_vector_from_block (nbytes=3D1040= ) at alloc.c:2900 > vector =3D 0x304b568 > block =3D 0x5cbd0d > index =3D 510 > restbytes =3D 140727746112864 > #3 0x00000000005ce9e0 in allocate_vectorlike (len=3D129) at alloc.= c:3108 > nbytes =3D 1040 > p =3D 0x5ce34e > #4 0x00000000005ceaed in allocate_vector (len=3D129) at alloc.c:31= 48 > v =3D 0x5cea61 > nbytes_max =3D 9223372036854775807 > #5 0x000000000054e894 in make_uninit_vector (size=3D129) at lisp.h= :3559 > v =3D 54491861 > p =3D 0x110 > #6 0x000000000054e8e0 in make_uninit_sub_char_table (depth=3D3, mi= n_char=3D64256) at lisp.h:3570 > slots =3D 129 > v =3D 60184035045 > #7 0x00000000004ee43b in make_sub_char_table (depth=3D3, min_char= =3D64256, defalt=3D0) at chartab.c:141 > i =3D 0 > table =3D 0 > #8 0x00000000004ef69a in sub_char_table_set_range (table=3D5449290= 1, from=3D64256, to=3D64262, val=3D50415725, is_uniprop=3Dfalse) at c= hartab.c:473 > sub =3D 0 > tbl =3D 0x33f7ee0 > depth =3D 2 > min_char =3D 61440 > chars_in_block =3D 128 > i =3D 22 > c =3D 64256 > lim =3D 32 > #9 0x00000000004ef6d4 in sub_char_table_set_range (table=3D1457533= 3, from=3D64256, to=3D64262, val=3D50415725, is_uniprop=3Dfalse) at c= hartab.c:477 > sub =3D 54492901 > tbl =3D 0xde66e0 > depth =3D 1 > min_char =3D 0 > chars_in_block =3D 4096 > i =3D 15 > c =3D 61440 > lim =3D 16 > #10 0x00000000004ef86c in char_table_set_range (table=3D52981493, f= rom=3D64256, to=3D64262, val=3D50415725) at chartab.c:511 > sub =3D 14575333 > is_uniprop =3D false > lim =3D 0 > i =3D 0 > c =3D 0 > tbl =3D 0x3286ef0 > #11 0x00000000004efeca in Fset_char_table_range (char_table=3D52981= 493, range=3D17504803, value=3D50415725) at chartab.c:654 > #12 0x0000000000680b3f in Fset_fontset_font (name=3D17419252, targe= t=3D29952, font_spec=3D15236741, frame=3D13456677, add=3D0) at fontse= t.c:1590 > fontset =3D 52981493 > font_def =3D 15103109 > registry =3D 17878196 > family =3D 0 > range_list =3D 17504787 > charset =3D 0x0 > fontname =3D 17878292 > ascii_changed =3D true > #13 0x0000000000681569 in fontset_from_font (font_object=3D50891429= ) at fontset.c:1757 > target =3D 29952 > font_name =3D 17419444 > font_spec =3D 15236741 > registry =3D 28656 > fontset_spec =3D 15395877 > alias =3D 17419220 > name =3D 17419252 > fontset =3D 52981493 > val =3D 0 The difference starts in this frame #13, inside fontset_from_font. O= n my system, this call returns where indicated below: int fontset_from_font (Lisp_Object font_object) { Lisp_Object font_name =3D font_get_name (font_object); Lisp_Object font_spec =3D copy_font_spec (font_object); Lisp_Object registry =3D AREF (font_spec, FONT_REGISTRY_INDEX); Lisp_Object fontset_spec, alias, name, fontset; Lisp_Object val; val =3D 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 ne= w frame? Finally, please give the exact sequence of commands you invoke to create a new frame, and what file/buffer is initially displayed in th= e new frame. (I used src/xdisp.c via "C-x 5 f".) I'd like to make sur= e we ask Emacs to do exactly the same job. > The lisp object arguments of interest are: >=20 > x_new_font: > font_object =3D # >=20 > Fset_fontset_font: > name =3D "-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*= -*-m-0-fontset-auto129" > target =3D latin > font_spec =3D # >=20 > here I get find_font_encoding() returning encoding =3D (unicode-b= mp). > CHARSET_SYMBOL_ID() then converts this encoding to 144 >=20 > Fset_char_table_range: > char_table =3D > range =3D (64256 . 64262) > value =3D [[# 144 nil]] For the record, the range (64256 . 64262) covers the Latin ligatures, like =EF=AC=80. DejaVu Sans Mono covers only 2 of them. On my syste= m, 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 Emac= s with a Courier font, and see if the problem still happens?