From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Sat, 21 Jan 2017 02:58:17 -0500 Message-ID: References: <8360ojpndr.fsf@gnu.org> <83shrnm0k1.fsf@gnu.org> <075B0922-F07A-4FBA-AE71-027E964A5ED4@raeburn.org> <54AAC13A-CF56-4393-A932-DC6CBBF51259@raeburn.org> <3CC6BB36-1794-4202-8243-132E0345B236@raeburn.org> <52BDCC33-546C-4F47-A230-00EBC813B038@raeburn.org> <15CF14CC-C7DE-44BA-AC7D-F0BF1F160979@raeburn.org> <9463F91F-DB82-48E1-BE01-1E2BC8DA0766@raeburn.org> <831swxzbw8.fsf@gnu.org> <83y3z2wphb.fsf@gnu.org> <83tw9bb42m.fsf@gnu.org> <349ED8B9-C34B-495B-9FB5-E72CE6EFCA38@raeburn.org> <87inpni6xa.fsf@linux-m68k.org> <8360lmesso.fsf@gnu.org> <3B044D64-7C94-42D7-BE1B-7A9CA76C5A67@raeburn.org> <83k29xc49v.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1484985550 10081 195.159.176.226 (21 Jan 2017 07:59:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 21 Jan 2017 07:59:10 +0000 (UTC) Cc: Andreas Schwab , Stefan Monnier , Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 21 08:59:04 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cUqZf-0001bU-H6 for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2017 08:58:59 +0100 Original-Received: from localhost ([::1]:59085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUqZi-0005qX-Tw for ged-emacs-devel@m.gmane.org; Sat, 21 Jan 2017 02:59:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cUqZ7-0005qQ-A2 for emacs-devel@gnu.org; Sat, 21 Jan 2017 02:58:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cUqZ4-0008FQ-4P for emacs-devel@gnu.org; Sat, 21 Jan 2017 02:58:25 -0500 Original-Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:35744) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cUqZ3-0008DR-VL for emacs-devel@gnu.org; Sat, 21 Jan 2017 02:58:22 -0500 Original-Received: by mail-qk0-x244.google.com with SMTP id u25so4438703qki.2 for ; Fri, 20 Jan 2017 23:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YW31bB/JKTslpBb1R8mjvubJz5Eyn4Zp/yE0jkC0nqc=; b=xOghQHudi03jZRRq8VCkrUgZYhRClG6aWE+qYXVSdg2GnBjcKTCC/5KFE6LhoJ+guD Z3WJIM8BS+fgWF5CfQb+R0aTPm8gjkiRYApq4nAiwCQ2e0ZtZqzhE07zMoaTZEPVJfEt Y4ntsx0u3CFlxFAIYICEHP0MbGdpyaxnjgst/H7UxqMSqPmFbtAYiVcf87BUw0efIF0r YtU+6tTd+hSf92k+eTvDxBAVjPDRw+Gq4wnrs3cK6wiubyTe5YG9yfukVD3SfUAlOLDP sFZpxMevbXw4GvI5JuEg1fwMFIOla3WSi4AxUnV1J5YqIM9EfVVm6WPeYnZBmhOICbjx WHJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YW31bB/JKTslpBb1R8mjvubJz5Eyn4Zp/yE0jkC0nqc=; b=BViKJw3GsTYmmensRWkHKD+41OOk8mXk0YVVUa9K8ZlnfUq+h/Nol0V+XZ6b27bysb uLZV7r2WZn3fBqx3exRkxHjEmJ0C/wIa8Q/VxWRQWjpXz36y311j7ec5VqObWbjwTkRQ Q4h5G+FGNK93MLJYHE7dGPhn7RCMDoJdozDErefaILOb039U8E3v2uztVSbbIf/gE6lE BqQgxlingrakw7YQ4IlmdcfSnXREmFjGRNUE1xfFMsSyQwbXqlOw3oYJ6JI6hNKbvqGJ FtfXc6wB+qIwOW2eRuua6VQwrM19CQeXTmNUR1/u7zGQFl8nCa0tqCe+erOLS2BWXVAx kWnw== X-Gm-Message-State: AIkVDXKIW9+hg3weAxdeQQVkE+yuOXwAPZwOcc4792vBBI/m0X7l2TyWJcirXIPdQRchww== X-Received: by 10.55.165.76 with SMTP id o73mr16148580qke.32.1484985499687; Fri, 20 Jan 2017 23:58:19 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id h40sm8040198qtb.6.2017.01.20.23.58.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Jan 2017 23:58:18 -0800 (PST) In-Reply-To: <83k29xc49v.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::244 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:211450 Archived-At: I think I may have figured out why I was getting crashes relating to the = face cache but it wasn=E2=80=99t very reproducible. Some of the face = creation code paths will ensure that a cache exists for a frame before = using it =E2=80=94 like the handling of =E2=80=9Cmenu=E2=80=9D in = internal-set-lisp-face-attribute =E2=80=94 and some do not. In a = regular Emacs build, the order of operations in the C and Lisp code = dictate the order in which face definitions are processed. So, for = example, in a batch-mode test invocation I tried, the =E2=80=9Cmenu=E2=80=9D= face handling created the cache for frame =E2=80=9CF1=E2=80=9D before = using it. But using dumped.elc, face property settings get restored, but the code = generated assumes that the order doesn=E2=80=99t matter, so the list of = face names depends not just on which Lisp code was loaded, but on the = order they=E2=80=99re seen under =E2=80=9Cmapatoms=E2=80=9D, i.e., based = on load order and the obarray size. (So my Mac/NS and GNU/Linux/X11 = builds have different lists of names, and different orders.) I=E2=80=99m looking at internal-set-lisp-face-attribute as a place to = always ensure the existence of the cache, but there may be a better = location. On Jan 14, 2017, at 05:41, Eli Zaretskii wrote: > [=E2=80=A6 much about failures I=E2=80=99m still looking at=E2=80=A6] > One other thing I noticed is that most of the *.elc files produced by > this build are different from those I see on master. The differences > are sometimes just a few bytes (e.g., in mule-diag.elc), but sometimes > much larger (e.g., files.elc). Perhaps this points to some subtle > problem in byte compilation? But even if so, that cannot explain the > failure to compile eww.el and ja-dic.el. I built a couple versions, and found several .elc files different. The = first case I looked at was macroexp--const-symbol-p in macroexp.elc. = =46rom disassembling, it appears that the expression =E2=80=9C(boundp = 'byte-compile-const-variables)=E2=80=9D is optimized out in the build = from the branch point, but not in the build including the dumped.elc = changes. I=E2=80=99m not sure why yet, but it=E2=80=99s almost = certainly a bug that they=E2=80=99re different. And a bug affecting the = emacs-lisp environment and/or the byte compiler output could certainly = cause later attempts at byte compilation (using newly byte-compiled = code) to misbehave. Ken=