From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: --with-native-compilation build failure on 32-bit systems Date: Thu, 18 Aug 2022 14:49:19 +0000 Message-ID: References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> <83h72lvf8g.fsf@gnu.org> <834jyace4m.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27290"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 18 16:50:51 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOgrC-0006ul-Vk for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 16:50:50 +0200 Original-Received: from localhost ([::1]:49848 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOgrB-0001sT-SQ for ged-emacs-devel@m.gmane-mx.org; Thu, 18 Aug 2022 10:50:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOgpw-0000Sb-Dg for emacs-devel@gnu.org; Thu, 18 Aug 2022 10:49:32 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:49239) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOgpu-0000CX-6z; Thu, 18 Aug 2022 10:49:32 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 27IEnJpl029871 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 18 Aug 2022 14:49:20 GMT In-Reply-To: (Stefan Monnier's message of "Thu, 18 Aug 2022 09:40:41 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293611 Archived-At: --=-=-= Content-Type: text/plain Stefan Monnier writes: >>> - I suspect there's some good reason I'm not aware of why we don't >>> eb539e92e9 at all (this is not necessary to fix the reported issue >>> tho). >> >> Like I said earlier, I always thought that this problem doesn't affect >> the pdumper builds. Perhaps that's not true with native-compilation? > > I can't see any good reason not to warn about purespace overflow, > regardless if it leads to misbehavior or not: we clearly do want to size > the purespace to avoid overflow. I agree. And I think we'd better to install also (other than my other suggested patch) the attached. This to warn not only at the end when dumping, but also in the moment the overflow happens. This helps debugging in case of a crash or analyzing the dynamic of an issue. Andrea --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-src-alloc.c-pure_alloc-Warn-for-pure-space-overflow.patch >From 89e034a7acef12ad187b95a8b45970c89fdc9e0b Mon Sep 17 00:00:00 2001 From: Andrea Corallo Date: Thu, 18 Aug 2022 16:41:26 +0200 Subject: [PATCH] * src/alloc.c (pure_alloc): Warn for pure space overflow --- src/alloc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/alloc.c b/src/alloc.c index 2ffee9f729..34bedac36b 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -5314,6 +5314,7 @@ valid_lisp_object_p (Lisp_Object obj) pure_alloc (size_t size, int type) { void *result; + static bool pure_overflow_warned = false; again: if (type >= 0) @@ -5338,6 +5339,12 @@ pure_alloc (size_t size, int type) if (pure_bytes_used <= pure_size) return result; + if (!pure_overflow_warned) + { + message ("Pure Lisp storage overflowed"); + pure_overflow_warned = true; + } + /* Don't allocate a large amount here, because it might get mmap'd and then its address might not be usable. */ -- 2.25.1 --=-=-=--