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 21:24:01 +0300 Message-ID: <83y4fhxjge.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> <83wpv1zr4q.fsf@gnu.org> <87egh9205z.fsf@secretsauce.net> <83r3l9zowx.fsf@gnu.org> <87d1wt1xe0.fsf@secretsauce.net> <87bncd1w88.fsf@secretsauce.net> <87a8rx1vmf.fsf@secretsauce.net> <83lhbhzj6b.fsf@gnu.org> <877fn118m5.fsf@secretsauce.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1444069476 14079 80.91.229.3 (5 Oct 2015 18:24:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 18:24:36 +0000 (UTC) Cc: schwab@suse.de, 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 20:24:27 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 1ZjAQz-0002sI-T6 for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 20:24:26 +0200 Original-Received: from localhost ([::1]:47150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjAQy-0006sH-SU for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 14:24:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjAQm-0006s5-IS for emacs-devel@gnu.org; Mon, 05 Oct 2015 14:24:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjAQi-0002rC-2F for emacs-devel@gnu.org; Mon, 05 Oct 2015 14:24:12 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:46544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjAQh-0002r0-Mt for emacs-devel@gnu.org; Mon, 05 Oct 2015 14:24:08 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NVR00H00EJHIK00@mtaout28.012.net.il> for emacs-devel@gnu.org; Mon, 05 Oct 2015 21:23:40 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVR00A27F3GXD80@mtaout28.012.net.il>; Mon, 05 Oct 2015 21:23:40 +0300 (IDT) In-reply-to: <877fn118m5.fsf@secretsauce.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 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:190955 Archived-At: > From: Dima Kogan > Cc: schwab@suse.de, eggert@cs.ucla.edu, emacs-devel@gnu.org > Date: Mon, 05 Oct 2015 11:19:14 -0700 > > >> > This better be always true, otherwise XCAR (XCAR (tail)) would be a bug. > >> > >> It isn't. Without that check I was getting every time. > >> > >> *ERROR*: Wrong type argument: listp, "monospace-10" > > > > I think what Andreas meant was this: the old code used > > XCAR (XCAR (tail)) unconditionally, which seems to indicate that > > XCAR (tail) is always a cons cell, and your test should always > > yield true. > > I just looked at it again, and it was my mistake; this is always a cons > cell as it should be. I was getting the error when using Fcopy_sequence > instead of making a new cell with Fcons. The former would make a deeper > copy, but the alist entries aren't lists, so Fcopy_sequence() was > barfing. Making a new cons-cell is one-level deep, and it's deep-enough, > so it works. So yeah, my bad. > > > >> Surprised me too, and I haven't checked to see what was happening there. > > > > So maybe your code should include some check for QCfont_entity in the > > 'else' clause as well. > > Here's the updated patch: > > diff --git a/src/font.c b/src/font.c > index 8e06532..dd574ca 100644 > --- a/src/font.c > +++ b/src/font.c > @@ -3981,7 +3981,12 @@ copy_font_spec (Lisp_Object font) > pcdr = spec->props + FONT_EXTRA_INDEX; > for (tail = AREF (font, FONT_EXTRA_INDEX); CONSP (tail); tail = XCDR (tail)) > if (!EQ (XCAR (XCAR (tail)), QCfont_entity)) > - *pcdr = Fcons (XCAR (tail), Qnil), pcdr = xcdr_addr (*pcdr); > + { > + *pcdr = Fcons (Fcons( XCAR (XCAR (tail)), > + XCDR (XCAR (tail))), > + Qnil); > + pcdr = xcdr_addr (*pcdr); > + } > > XSETFONT (new_spec, spec); > return new_spec; > > I'm not sure what you mean about checking for QCfont_entity. This new > patch doesn't add an if(), and there's already a QCfont_entity check > there. This is fine, right? Forget that. It was based on your reports about errors.