unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrea Corallo <akrl@sdf.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Eli Zaretskii <eliz@gnu.org>,
	larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org,
	emacs@FreeBSD.org
Subject: Re: --with-native-compilation build failure on 32-bit systems
Date: Thu, 18 Aug 2022 14:49:19 +0000	[thread overview]
Message-ID: <xjfedxdhaj4.fsf@ma.sdf.org> (raw)
In-Reply-To: <jwvmtc18yeu.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Thu, 18 Aug 2022 09:40:41 -0400")

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> 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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-src-alloc.c-pure_alloc-Warn-for-pure-space-overflow.patch --]
[-- Type: text/x-diff, Size: 972 bytes --]

From 89e034a7acef12ad187b95a8b45970c89fdc9e0b Mon Sep 17 00:00:00 2001
From: Andrea Corallo <akrl@sdf.org>
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


  parent reply	other threads:[~2022-08-18 14:49 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05  2:12 --with-native-compilation build failure on 32-bit systems Joseph Mingrone
2022-08-05 11:58 ` Lars Ingebrigtsen
2022-08-05 13:30   ` Andrea Corallo
2022-08-05 14:40     ` Andrea Corallo
2022-08-05 15:16       ` Lynn Winebarger
2022-08-08  7:44         ` Andrea Corallo
2022-08-08 10:22           ` Lynn Winebarger
2022-08-08 13:14             ` Andrea Corallo
2022-08-08 13:55               ` Lynn Winebarger
2022-08-08 14:13                 ` Andrea Corallo
2022-08-09  9:11       ` Andrea Corallo
2022-08-09  9:21         ` Andrea Corallo
2022-08-09  9:48           ` Po Lu
2022-08-09 10:03             ` Andrea Corallo
2022-08-09 10:10               ` Po Lu
2022-08-09 10:20           ` Lynn Winebarger
2022-08-09 11:16           ` Eli Zaretskii
2022-08-17 19:59             ` Andrea Corallo
2022-08-17 21:01               ` Andrea Corallo
2022-08-18  5:30                 ` Eli Zaretskii
2022-08-18  8:06                   ` Andrea Corallo
2022-08-18  8:15                     ` Eli Zaretskii
2022-08-18  9:08                       ` Andrea Corallo
2022-08-18  8:31                     ` Po Lu
2022-08-18 11:48                     ` Joseph Mingrone
2022-08-18 13:40                   ` Stefan Monnier
2022-08-18 13:47                     ` Lynn Winebarger
2022-08-18 14:49                     ` Andrea Corallo [this message]
2022-08-18  5:17               ` Eli Zaretskii
2022-08-18  7:59                 ` Andrea Corallo
2022-08-18  8:14                   ` Eli Zaretskii
2022-08-18  9:06                     ` Andrea Corallo
2022-08-18  9:45                       ` Eli Zaretskii
2022-08-18  9:57                         ` Andrea Corallo
2022-08-18 10:31                           ` Eli Zaretskii
2022-08-18 11:08                             ` Andrea Corallo
2022-08-18 13:08                               ` Eli Zaretskii
2022-08-18 14:09                                 ` Andrea Corallo
2022-08-18 14:22                                   ` Eli Zaretskii
2022-08-18 14:50                                     ` Andrea Corallo
2022-08-18 15:57                                       ` Eli Zaretskii
2022-08-18 16:42                                         ` Andrea Corallo
2022-08-18 17:11                                           ` Eli Zaretskii
2022-08-18 19:35                                             ` Andrea Corallo
2022-08-19  5:49                                               ` Eli Zaretskii
2022-08-19  8:11                                                 ` Andrea Corallo
2022-08-09 15:32           ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xjfedxdhaj4.fsf@ma.sdf.org \
    --to=akrl@sdf.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=emacs@FreeBSD.org \
    --cc=jrm@ftfl.ca \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).