Received: (at 80712) by debbugs.gnu.org; 5 Apr 2026 11:30:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 05 07:30:59 2026
Received: from localhost ([127.0.0.1]:57072 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w9Lgu-0006ls-7y
for submit <at> debbugs.gnu.org; Sun, 05 Apr 2026 07:30:58 -0400
Received: from mail-10631.protonmail.ch ([79.135.106.31]:52019)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1w9Lgo-0006Q4-VV
for 80712 <at> debbugs.gnu.org; Sun, 05 Apr 2026 07:30:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1775388642; x=1775647842;
bh=3q273yTrlVH+UejGdeRJjPJgpRibrPhTf2ww6Ntny3k=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=bbyQhFq8gwthb4NFeRsc0fR6yAicDGguWbGtHg7karr6AFleXYu3qJMmq87tveHXT
gbJ23mNhHT6JwjcpyMHNspvAQA5Uo7sEMTjgLMxylEy1GOk6sNGNj3tYCEf21+jyac
QuHFuYfDYOgtypvaR8UHQ34hQKf2M4BUDG1qlbpyvWPVfUTrAtdSCvdaNoKrtMlCW5
6t0ohmqC3YMRMiNf+4LRZ3zia++31yDXBtQJbYX3nvUDyCOXTVU9JtQDaW5KBSm1zE
MN2xt31vAisJPPSrsGpr2GGz/fQKF0yGHZcsddFo3fJUGbpDknQ/VyoVJMnG6Y7vqN
hEbmX6I2EJQqw==
Date: Sun, 05 Apr 2026 11:30:35 +0000
To: Helmut Eller <eller.helmut@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
Message-ID: <87v7e5ve2w.fsf@HIDDEN>
In-Reply-To: <87jyulkclh.fsf@HIDDEN>
References: <87ikac7yho.fsf@localhost> <87cy0k7x2u.fsf@localhost>
<87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN>
<86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN>
<87qzoujymy.fsf@HIDDEN> <87a4viwkxe.fsf@HIDDEN>
<87jyulkclh.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: d33a1114376aaed7354e50e3c65d9de6d657e318
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80712
Cc: 80712 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Pip Cet <pipcet@HIDDEN> writes:
> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>
>> On Sat, Apr 04 2026, Pip Cet wrote:
>>
>>> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>>>
>>>>> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 200=
1
>>>>> From: Pip Cet <pipcet@HIDDEN>
>>>>> Date: Sat, 4 Apr 2026 17:16:38 +0000
>>>>> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#7670=
5,
>>>>> bug#80712)
>>>>>
>>>>> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New
>>>>> variables.
>>>>> (count_maps): New.
>>>>> (ProtSet): Avoid unbounded mprotect calls.
>>>>> (ProtSync): Clean up after potentially skipping mprotect calls.
>>>>
>>>> So the basic idea is: if mprotect fails, then ProtSet becomes a noop a=
nd
>>>> ProtSync will be used instead?
>>>
>>> No.
>>>
>>> First, we should never let mprotect fail: if it does, we've exhausted
>>> all maps, and other code might try an mmap (or malloc) and fail, or
>>> already have done so. So we use a "budget" instead, chosen so that even
>>> in the worst case, the number of maps won't reach MAGIC NUMBER (6000 fo=
r
>>> testing, 60000 for production).
>>>
>>> ProtSet doesn't become a noop: we still need it to remove barriers, but
>>> we'll refuse to install new ones.
>>>
>>> And ProtSync forcibly triggers all memory barriers after an emergency
>>> (it's taken from protan.c), which will hopefully reduce the number of
>>> maps so much that the next emergency won't be just around the corner.
>>
>> OK. I see no reason why this wouldn't work. This should be tested
>> however.
>
> I agree, and that's why the numbers chosen were so low: I found it kind
> of difficult to hit the 65530 limit reliably (not that I've tried very
> hard).
This seems to work if I override the limit so I actually hit it.
Rationale:
1. A new message type for "GC aborts". I think that's a useful category
to have: something happened which caused us to finish the GC
synchronously and remove all memory barriers; leave it up to the
application code whether to move the arena into a postmortem state or
continue operating as normal (displaying the message to the user).
I originally thought it might be nice to be able to interrupt a running
GC, but it's harder than I thought :-)
Note that this is a very large patch.
2. protli.c rather than protix.c. The problem is Linux-specific, and the
solution even more so.
This is based on the idea that we run out of the budget quite rarely, so
it's not too much of a loss to reread /proc/sys/vm/max_map_count in case
it has been increased. (If it's decreased, we lose, most likely).
3. Display the messages even if garbage_collection_messages is false:
they're extraordinary and we should know about them. However, don't do
it in noninteractive sessions since those might (unwisely) rely on the
Emacs output.
Should this be a warning instead of a mere message?
4. Don't abort for now: my understanding is that the problem is caused
by a very specific pattern of used and unused areas in memory. However,
when we perform GC, the "used" areas end up together (usually), because
they're copied, so I hope the problem will usually "go away" after
GC.
WDYT?
TODO:
- make SLACK configurable (it's currently fixed at 1024)
- better messages (ideally, indicating the current/max map count)
- find a test
- check some assertions in the MPS code. In particular, this one:
CHECKL(!arena->tsMessage[ti] || arena->tMessage[ti]);
I'm not sure what this tests and how to adjust it for the new taMessage
field. Helmut, do you happen to know?
From b78c217ac9a35a4e6301b5ab23f5d4cc9f87b1fc Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Sun, 5 Apr 2026 11:01:57 +0000
Subject: [PATCH 1/3] Add a "trace aborted" message type to MPS
Currently only used for running out of mprotect calls.
* mps/code/global.c (GlobalsInit): Add taMessage.
* mps/code/message.c (MessageGCAbortWhy):
(MessageNoGCAbortWhy): New.
* mps/code/mpmst.h (MessageClassStruct): Add AbortWhyMethod.
(ArenaStruct): Add taMessage.
* mps/code/mpsi.c (mps_message_gc_abort_why): New.
* mps/code/poolmrg.c (MRGMessageClassStruct): Add MessageNoGCAbortWhy.
* mps/code/traceanc.c (TraceStartMessageClassStruct): Adjust.
(TraceAbortMessageSig):
(TraceAbortMessageMessage):
(TraceAbortMessageDelete):
(TraceAbortMessageWhy):
(TraceAbortMessageClassStruct):
(traceAbortMessageInit):
(TraceAbortWhyToString):
(traceAbortWhyToTextBuffer):
(TracePostAbortMessage): New.
(TraceMessageClassStruct):
(TraceIdMessagesCheck):
(TraceIdMessagesCreate):
(TraceIdMessagesDestroy): Adjust.
---
mps/code/global.c | 1 +
mps/code/message.c | 18 ++++
mps/code/mpm.h | 2 +
mps/code/mpmst.h | 4 +
mps/code/mpmtypes.h | 20 ++++
mps/code/mps.h | 7 +-
mps/code/mpsi.c | 21 ++++
mps/code/poolmrg.c | 1 +
mps/code/traceanc.c | 231 ++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 304 insertions(+), 1 deletion(-)
diff --git a/mps/code/global.c b/mps/code/global.c
index 08e9d3c8c0f..50cf1a44c6f 100644
--- a/mps/code/global.c
+++ b/mps/code/global.c
@@ -335,6 +335,7 @@ SRCID(global, "$Id$");
arena->trace[ti].ti =3D ti;
/* <design/message-gc#.lifecycle> */
arena->tsMessage[ti] =3D NULL;
+ arena->taMessage[ti] =3D NULL;
arena->tMessage[ti] =3D NULL;
}
=20
diff --git a/mps/code/message.c b/mps/code/message.c
index 476127db99f..a058233c747 100644
--- a/mps/code/message.c
+++ b/mps/code/message.c
@@ -368,6 +368,14 @@ #define MessageIsClocked(message) \
return (*message->klass->gcStartWhy)(message);
}
=20
+const char *MessageGCAbortWhy(Message message)
+{
+ AVERT(Message, message);
+ AVER(MessageGetType(message) =3D=3D MessageTypeGCABORT);
+
+ return (*message->klass->gcAbortWhy)(message);
+}
+
=20
/* Message Method Stubs, Type-specific
*
@@ -424,6 +432,16 @@ #define MessageIsClocked(message) \
return NULL;
}
=20
+const char *MessageNoGCAbortWhy(Message message)
+{
+ AVERT(Message, message);
+ UNUSED(message);
+
+ NOTREACHED;
+
+ return NULL;
+}
+
=20
/* C. COPYRIGHT AND LICENSE
*
diff --git a/mps/code/mpm.h b/mps/code/mpm.h
index e072a7a1ea7..08c3de9a710 100644
--- a/mps/code/mpm.h
+++ b/mps/code/mpm.h
@@ -319,6 +319,7 @@ DECLARE_CLASS(Pool, AbstractCollectPool, AbstractSegBuf=
Pool);
extern Size MessageGCCondemnedSize(Message message);
extern Size MessageGCNotCondemnedSize(Message message);
extern const char *MessageGCStartWhy(Message message);
+extern const char *MessageGCAbortWhy(Message message);
/* -- Message Method Stubs, Type-specific */
extern void MessageNoFinalizationRef(Ref *refReturn,
Arena arena, Message message);
@@ -326,6 +327,7 @@ DECLARE_CLASS(Pool, AbstractCollectPool, AbstractSegBuf=
Pool);
extern Size MessageNoGCCondemnedSize(Message message);
extern Size MessageNoGCNotCondemnedSize(Message message);
extern const char *MessageNoGCStartWhy(Message message);
+extern const char *MessageNoGCAbortWhy(Message message);
=20
=20
/* Trace Interface -- see <code/trace.c> */
diff --git a/mps/code/mpmst.h b/mps/code/mpmst.h
index 219802505f4..bb66db0940f 100644
--- a/mps/code/mpmst.h
+++ b/mps/code/mpmst.h
@@ -152,6 +152,9 @@ #define MessageClassSig ((Sig)0x519359c1) /* SIGnature =
MeSsaGe CLass */
/* methods specific to MessageTypeGCSTART */
MessageGCStartWhyMethod gcStartWhy;
=20
+ /* methods specific to MessageTypeGCABORT */
+ MessageGCAbortWhyMethod gcAbortWhy;
+
Sig endSig; /* <design/message#.class.sig.double> */
} MessageClassStruct;
=20
@@ -802,6 +805,7 @@ #define ArenaSig ((Sig)0x519A6E4A) /* SIGnature =
ARENA */
=20
/* trace ancillary fields <code/traceanc.c> */
TraceStartMessage tsMessage[TraceLIMIT]; /* <design/message-gc> */
+ TraceAbortMessage taMessage[TraceLIMIT]; /* <design/message-gc> */
TraceMessage tMessage[TraceLIMIT]; /* <design/message-gc> */
=20
/* policy fields */
diff --git a/mps/code/mpmtypes.h b/mps/code/mpmtypes.h
index ba7fa32c855..7fc4c89d2f3 100644
--- a/mps/code/mpmtypes.h
+++ b/mps/code/mpmtypes.h
@@ -61,6 +61,7 @@ #define mpmtypes_h
typedef unsigned TraceSet; /* <design/type#.traceset> */
typedef unsigned TraceState; /* <design/type#.tracestate> */
typedef unsigned TraceStartWhy; /* <design/type#.tracestartwhy> */
+typedef unsigned TraceAbortWhy;
typedef unsigned AccessSet; /* <design/type#.access-set> */
typedef unsigned Attr; /* <design/type#.attr> */
typedef unsigned RootVar; /* <design/type#.rootvar> */
@@ -239,10 +240,12 @@ #define mpmtypes_h
typedef Size (*MessageGCCondemnedSizeMethod)(Message message);
typedef Size (*MessageGCNotCondemnedSizeMethod)(Message message);
typedef const char * (*MessageGCStartWhyMethod)(Message message);
+typedef const char * (*MessageGCAbortWhyMethod)(Message message);
=20
/* Message Types -- <design/message> and elsewhere */
=20
typedef struct TraceStartMessageStruct *TraceStartMessage;
+typedef struct TraceAbortMessageStruct *TraceAbortMessage;
typedef struct TraceMessageStruct *TraceMessage; /* trace end */
=20
=20
@@ -390,6 +393,22 @@ #define X(WHY, SHORT, LONG) TraceStartWhy ## WHY,
};
=20
=20
+/* TraceAbort reasons: what caused an incremental trace to abort. */
+/* Make these specific reasons, not broad categories; */
+/* and if a new reason is added, add a new message. */
+
+#define TRACE_ABORT_WHY_LIST(X) \
+ X(MPROTECT_LIMIT, "mprotect budget exhausted", \
+ "Too many mprotected areas")=09=09=09=09=09\
+
+enum {
+#define X(WHY, SHORT, LONG) TraceAbortWhy ## WHY,
+ TRACE_ABORT_WHY_LIST(X)
+#undef X
+ TraceAbortWhyLIMIT
+};
+
+
/* MessageTypes -- see <design/message> */
/* .message.types: Keep in sync with <code/mps.h#message.types> */
=20
@@ -397,6 +416,7 @@ #define X(WHY, SHORT, LONG) TraceStartWhy ## WHY,
MessageTypeFINALIZATION, /* MPS_MESSAGE_TYPE_FINALIZATION */
MessageTypeGC, /* MPS_MESSAGE_TYPE_GC =3D trace end */
MessageTypeGCSTART, /* MPS_MESSAGE_TYPE_GC_START */
+ MessageTypeGCABORT, /* MPS_MESSAGE_TYPE_GC_ABORT */
MessageTypeLIMIT /* not a message type, the limit of the enum. */
};
=20
diff --git a/mps/code/mps.h b/mps/code/mps.h
index 9f45debc1a8..3646e9a6bef 100644
--- a/mps/code/mps.h
+++ b/mps/code/mps.h
@@ -304,7 +304,8 @@ #define MPS_ARGS_END(_var) \
enum {
_mps_MESSAGE_TYPE_FINALIZATION,
_mps_MESSAGE_TYPE_GC,
- _mps_MESSAGE_TYPE_GC_START
+ _mps_MESSAGE_TYPE_GC_START,
+ _mps_MESSAGE_TYPE_GC_ABORT
};
=20
/* Message Types
@@ -312,6 +313,7 @@ #define MPS_ARGS_END(_var) \
#define mps_message_type_finalization() _mps_MESSAGE_TYPE_FINALIZATION
#define mps_message_type_gc() _mps_MESSAGE_TYPE_GC
#define mps_message_type_gc_start() _mps_MESSAGE_TYPE_GC_START
+#define mps_message_type_gc_abort() _mps_MESSAGE_TYPE_GC_ABORT
=20
=20
/* Reference Ranks
@@ -752,6 +754,9 @@ #define mps_commit(_mps_ap, _p, _size) \
/* -- mps_message_type_gc_start */
extern const char *mps_message_gc_start_why(mps_arena_t, mps_message_t);
=20
+/* -- mps_message_type_gc_abort */
+extern const char *mps_message_gc_abort_why(mps_arena_t, mps_message_t);
+
=20
/* Finalization */
=20
diff --git a/mps/code/mpsi.c b/mps/code/mpsi.c
index fb43ec6decc..a42408ab940 100644
--- a/mps/code/mpsi.c
+++ b/mps/code/mpsi.c
@@ -83,6 +83,8 @@ SRCID(mpsi, "$Id$");
=3D=3D (int)_mps_MESSAGE_TYPE_GC);
CHECKL((int)MessageTypeGCSTART
=3D=3D (int)_mps_MESSAGE_TYPE_GC_START);
+ CHECKL((int)MessageTypeGCABORT
+ =3D=3D (int)_mps_MESSAGE_TYPE_GC_ABORT);
=20
/* The external idea of a word width and the internal one */
/* had better match. <design/interface-c#.cons>. */
@@ -1940,6 +1942,25 @@ mps_res_t (mps_ap_frame_pop)(mps_ap_t mps_ap, mps_fr=
ame_t frame)
}
=20
=20
+/* -- mps_message_type_gc_abort */
+
+const char *mps_message_gc_abort_why(mps_arena_t arena,
+ mps_message_t message)
+{
+ const char *s;
+
+ ArenaEnter(arena);
+
+ AVERT(Arena, arena);
+
+ s =3D MessageGCAbortWhy(message);
+
+ ArenaLeave(arena);
+
+ return s;
+}
+
+
/* Telemetry */
=20
/* TODO: need to consider locking. See job003387, job003388. */
diff --git a/mps/code/poolmrg.c b/mps/code/poolmrg.c
index a898634f7d5..e73a71d311c 100644
--- a/mps/code/poolmrg.c
+++ b/mps/code/poolmrg.c
@@ -477,6 +477,7 @@ #define linkOfIndex(linkseg, index) \
MessageNoGCCondemnedSize, /* GCCondemnedSize */
MessageNoGCNotCondemnedSize, /* GCNotCondemnedSize */
MessageNoGCStartWhy, /* GCStartWhy */
+ MessageNoGCAbortWhy, /* GCAbortWhy */
MessageClassSig /* <design/message#.class.sig.double> */
};
=20
diff --git a/mps/code/traceanc.c b/mps/code/traceanc.c
index a6f4f3f49cc..e07979c9afd 100644
--- a/mps/code/traceanc.c
+++ b/mps/code/traceanc.c
@@ -117,6 +117,7 @@ #define MessageTraceStartMessage(message) \
MessageNoGCCondemnedSize, /* GCCondemnedSize */
MessageNoGCNotCondemnedSize, /* GCNotCondemnedSize */
TraceStartMessageWhy, /* GCStartWhy */
+ MessageNoGCAbortWhy, /* GCAbortWhy */
MessageClassSig /* <design/message#.class.sig.double> */
};
=20
@@ -227,6 +228,207 @@ #define X(WHY, SHORT, LONG) case TraceStartWhy ## WHY=
: r =3D (LONG); break;
=20
=20
=20
+/* -------- TraceAbortMessage -------- */
+
+
+/* TraceAbortMessage -- posted when a trace aborts
+ *
+ * Internal names:
+ * trace abort
+ * TraceAbortMessage, taMessage (struct *)
+ * MessageTypeGCABORT (enum)
+ *
+ * External names:
+ * mps_message_type_gc_abort (enum macro)
+ * MPS_MESSAGE_TYPE_GC_ABORT (enum)
+ *
+ * <design/message-gc>.
+ */
+
+#define TraceAbortMessageSig ((Sig)0x51926A35) /* SIGnature TRaceAbortMeSs=
age */
+
+/* .whybuf:
+ * .whybuf.len: Length (in chars) of a char buffer used to store the
+ * reason why a collection was aborted in the TraceAbortMessageStruct
+ * (used by mps_message_type_gc_abort). If the reason is too long to
+ * fit, it must be truncated.
+ * .whybuf.nul: Check insists that the last char in the array is NUL
+ * (even if there is another NUL earlier in the buffer); this makes
+ * the NUL-termination check fast.
+ */
+#define TRACE_ABORT_MESSAGE_WHYBUF_LEN 128
+
+typedef struct TraceAbortMessageStruct {
+ Sig sig; /* design.mps.sig.field */
+ char why[TRACE_ABORT_MESSAGE_WHYBUF_LEN]; /* .whybuf */
+ MessageStruct messageStruct;
+} TraceAbortMessageStruct;
+
+#define TraceAbortMessageMessage(traceAbortMessage) \
+ (&((traceAbortMessage)->messageStruct))
+#define MessageTraceAbortMessage(message) \
+ (PARENT(TraceAbortMessageStruct, messageStruct, message))
+
+Bool TraceAbortMessageCheck(TraceAbortMessage taMessage)
+{
+ CHECKS(TraceAbortMessage, taMessage);
+ CHECKD(Message, TraceAbortMessageMessage(taMessage));
+ CHECKL(MessageGetType(TraceAbortMessageMessage(taMessage)) =3D=3D
+ MessageTypeGCABORT);
+
+ /* Check that why is NUL terminated. See .whybuf.nul */
+ CHECKL(taMessage->why[NELEMS(taMessage->why)-1] =3D=3D '\0');
+
+ return TRUE;
+}
+
+static void TraceAbortMessageDelete(Message message)
+{
+ TraceAbortMessage taMessage;
+ Arena arena;
+
+ AVERT(Message, message);
+ taMessage =3D MessageTraceAbortMessage(message);
+ AVERT(TraceAbortMessage, taMessage);
+
+ arena =3D MessageArena(message);
+ taMessage->sig =3D SigInvalid;
+ MessageFinish(message);
+
+ ControlFree(arena, (void *)taMessage, sizeof(TraceAbortMessageStruct));
+}
+
+static const char *TraceAbortMessageWhy(Message message)
+{
+ TraceAbortMessage taMessage;
+
+ AVERT(Message, message);
+ taMessage =3D MessageTraceAbortMessage(message);
+ AVERT(TraceAbortMessage, taMessage);
+
+ return taMessage->why;
+}
+
+static MessageClassStruct TraceAbortMessageClassStruct =3D {
+ MessageClassSig, /* sig */
+ "TraceGCAbort", /* name */
+ MessageTypeGCABORT, /* Message Type */
+ TraceAbortMessageDelete, /* Delete */
+ MessageNoFinalizationRef, /* FinalizationRef */
+ MessageNoGCLiveSize, /* GCLiveSize */
+ MessageNoGCCondemnedSize, /* GCCondemnedSize */
+ MessageNoGCNotCondemnedSize, /* GCNotCondemnedSize */
+ MessageNoGCStartWhy, /* GCStartWhy */
+ TraceAbortMessageWhy, /* GCAbortWhy */
+ MessageClassSig /* <design/message#.class.sig.double> */
+};
+
+static void traceAbortMessageInit(Arena arena, TraceAbortMessage taMessage=
)
+{
+ AVERT(Arena, arena);
+
+ MessageInit(arena, TraceAbortMessageMessage(taMessage),
+ &TraceAbortMessageClassStruct, MessageTypeGCABORT);
+ taMessage->why[0] =3D '\0';
+ taMessage->why[NELEMS(taMessage->why)-1] =3D '\0'; /* .whybuf.nul */
+
+ taMessage->sig =3D TraceAbortMessageSig;
+ AVERT(TraceAbortMessage, taMessage);
+}
+
+/* TraceAbortWhyToString -- why-code to text
+ *
+ * Converts a TraceAbortWhy* code into a constant string describing
+ * why a trace aborted.
+ */
+
+const char *TraceAbortWhyToString(TraceAbortWhy why)
+{
+ const char *r;
+
+ switch (why) {
+#define X(WHY, SHORT, LONG) case TraceAbortWhy ## WHY: r =3D (LONG); break=
;
+ TRACE_ABORT_WHY_LIST(X)
+#undef X
+ default:
+ NOTREACHED;
+ r =3D "Unknown reason (internal error).";
+ break;
+ }
+
+ /* Must fit in buffer without truncation; see .whybuf.len */
+ AVER(StringLength(r) < TRACE_ABORT_MESSAGE_WHYBUF_LEN);
+
+ return r;
+}
+
+
+/* traceAbortWhyToTextBuffer
+ *
+ * Converts a TraceAbortWhy* code into a string describing why a trace
+ * was aborted, and copies that into the text buffer the caller provides.
+ * s specifies the beginning of the buffer to write the string
+ * into, len specifies the length of the buffer.
+ * The string written will be NUL terminated, and truncated if
+ * necessary.
+ */
+
+static void traceAbortWhyToTextBuffer(char *s, size_t len, TraceAbortWhy w=
hy)
+{
+ const char *r;
+ size_t i;
+
+ AVER(s);
+ /* len can be anything, including 0. */
+ AVER(why < TraceAbortWhyLIMIT);
+
+ r =3D TraceAbortWhyToString(why);
+
+ for(i=3D0; i<len; ++i) {
+ s[i] =3D r[i];
+ if(r[i] =3D=3D '\0')
+ break;
+ }
+ s[len-1] =3D '\0'; /* .whybuf.nul */
+}
+
+/* TracePostAbortMessage -- complete and post trace abort message
+ *
+ */
+
+void TracePostAbortMessage(Trace trace, TraceAbortWhy why)
+{
+ Arena arena;
+ TraceId ti;
+ TraceAbortMessage taMessage;
+
+ AVERT(Trace, trace);
+
+ arena =3D trace->arena;
+ AVERT(Arena, arena);
+
+ ti =3D trace->ti;
+ AVERT(TraceId, ti);
+
+ taMessage =3D arena->taMessage[ti];
+ if(taMessage) {
+ AVERT(TraceAbortMessage, taMessage);
+
+ traceAbortWhyToTextBuffer(taMessage->why,
+ sizeof taMessage->why, why);
+
+ arena->taMessage[ti] =3D NULL;
+ MessagePost(arena, TraceAbortMessageMessage(taMessage));
+ } else {
+ arena->droppedMessages +=3D 1;
+ }
+
+ /* We have consumed the pre-allocated message */
+ AVER(!arena->taMessage[ti]);
+}
+
+
+
/* -------- TraceMessage (trace end) -------- */
=20
=20
@@ -335,6 +537,7 @@ #define MessageTraceMessage(message) \
TraceMessageCondemnedSize, /* GCCondemnedSize */
TraceMessageNotCondemnedSize, /* GCNotCondemnedSize */
MessageNoGCStartWhy, /* GCStartWhy */
+ MessageNoGCAbortWhy, /* GCAbortWhy */
MessageClassSig /* <design/message#.class.sig.double> */
};
=20
@@ -415,6 +618,7 @@ #define MessageTraceMessage(message) \
{
CHECKL(!arena->tsMessage[ti] || TraceStartMessageCheck(arena->tsMessage[=
ti]));
CHECKL(!arena->tsMessage[ti] || arena->tMessage[ti]);
+ CHECKL(!arena->taMessage[ti] || TraceAbortMessageCheck(arena->taMessage[=
ti]));
CHECKL(!arena->tMessage[ti] || TraceMessageCheck(arena->tMessage[ti]));
=20
return TRUE;
@@ -434,6 +638,7 @@ #define MessageTraceMessage(message) \
{
void *p;
TraceStartMessage tsMessage;
+ TraceAbortMessage taMessage;
TraceMessage tMessage;
Res res;
=20
@@ -446,6 +651,15 @@ #define MessageTraceMessage(message) \
goto failTraceStartMessage;
tsMessage =3D p;
=20
+ if (!arena->taMessage[ti]) {
+ res =3D ControlAlloc(&p, arena, sizeof(TraceAbortMessageStruct));
+ if(res !=3D ResOK)
+ goto failTraceAbortMessage;
+ taMessage =3D p;
+ } else {
+ taMessage =3D NULL;
+ }
+
res =3D ControlAlloc(&p, arena, sizeof(TraceMessageStruct));
if(res !=3D ResOK)
goto failTraceMessage;
@@ -454,10 +668,17 @@ #define MessageTraceMessage(message) \
traceStartMessageInit(arena, tsMessage);
AVERT(TraceStartMessage, tsMessage);
=20
+ if (taMessage) {
+ traceAbortMessageInit(arena, taMessage);
+ AVERT(TraceAbortMessage, taMessage);
+ }
+
traceMessageInit(arena, tMessage);
AVERT(TraceMessage, tMessage);
=20
arena->tsMessage[ti] =3D tsMessage;
+ if (taMessage)
+ arena->taMessage[ti] =3D taMessage;
arena->tMessage[ti] =3D tMessage;
=20
AVER(TraceIdMessagesCheck(arena, ti));
@@ -465,6 +686,8 @@ #define MessageTraceMessage(message) \
return ResOK;
=20
failTraceMessage:
+ ControlFree(arena, taMessage, sizeof(TraceAbortMessageStruct));
+failTraceAbortMessage:
ControlFree(arena, tsMessage, sizeof(TraceStartMessageStruct));
failTraceStartMessage:
AVER(TraceIdMessagesCheck(arena, ti));
@@ -481,6 +704,7 @@ #define MessageTraceMessage(message) \
void TraceIdMessagesDestroy(Arena arena, TraceId ti)
{
TraceStartMessage tsMessage;
+ TraceAbortMessage taMessage;
TraceMessage tMessage;
=20
AVER(TraceIdMessagesCheck(arena, ti));
@@ -491,6 +715,12 @@ #define MessageTraceMessage(message) \
TraceStartMessageDelete(TraceStartMessageMessage(tsMessage));
}
=20
+ taMessage =3D arena->taMessage[ti];
+ if(taMessage) {
+ arena->taMessage[ti] =3D NULL;
+ TraceAbortMessageDelete(TraceAbortMessageMessage(taMessage));
+ }
+
tMessage =3D arena->tMessage[ti];
if(tMessage) {
arena->tMessage[ti] =3D NULL;
@@ -498,6 +728,7 @@ #define MessageTraceMessage(message) \
}
=20
AVER(!arena->tsMessage[ti]);
+ AVER(!arena->taMessage[ti]);
AVER(!arena->tMessage[ti]);
AVER(TraceIdMessagesCheck(arena, ti));
}
--=20
2.53.0
From 28c67be396fc299bdb1cba510ef88cd3a75e86ef Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Sun, 5 Apr 2026 11:07:06 +0000
Subject: [PATCH 2/3] Switch MPS Linux builds to protli.c
* mps/code/lia6gc.gmk:
* mps/code/lia6ll.gmk:
* mps/code/lii3gc.gmk:
* mps/code/lii6gc.gmk:
* mps/code/lii6ll.gmk:
* mps/code/mps.c: Use "protli.c" where appropriate.
* mps/code/protli.c: New file.
---
mps/code/lia6gc.gmk | 2 +-
mps/code/lia6ll.gmk | 2 +-
mps/code/lii3gc.gmk | 2 +-
mps/code/lii6gc.gmk | 2 +-
mps/code/lii6ll.gmk | 2 +-
mps/code/mps.c | 6 +-
mps/code/protli.c | 252 ++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 260 insertions(+), 8 deletions(-)
create mode 100644 mps/code/protli.c
diff --git a/mps/code/lia6gc.gmk b/mps/code/lia6gc.gmk
index 1c6437f68a0..90b1e8dd484 100644
--- a/mps/code/lia6gc.gmk
+++ b/mps/code/lia6gc.gmk
@@ -12,7 +12,7 @@ MPMPF =3D \
prmcanan.c \
prmcix.c \
prmclia6.c \
- protix.c \
+ protli.c \
protsgix.c \
pthrdext.c \
span.c \
diff --git a/mps/code/lia6ll.gmk b/mps/code/lia6ll.gmk
index 9e329ee98a4..ab51181f777 100644
--- a/mps/code/lia6ll.gmk
+++ b/mps/code/lia6ll.gmk
@@ -12,7 +12,7 @@ MPMPF =3D \
prmcanan.c \
prmcix.c \
prmclia6.c \
- protix.c \
+ protli.c \
protsgix.c \
pthrdext.c \
span.c \
diff --git a/mps/code/lii3gc.gmk b/mps/code/lii3gc.gmk
index 8ad1b103e89..8e563cbe8d2 100644
--- a/mps/code/lii3gc.gmk
+++ b/mps/code/lii3gc.gmk
@@ -12,7 +12,7 @@ MPMPF =3D \
prmci3.c \
prmcix.c \
prmclii3.c \
- protix.c \
+ protli.c \
protsgix.c \
pthrdext.c \
span.c \
diff --git a/mps/code/lii6gc.gmk b/mps/code/lii6gc.gmk
index 9b73752ec16..a1c5d5b2dee 100644
--- a/mps/code/lii6gc.gmk
+++ b/mps/code/lii6gc.gmk
@@ -12,7 +12,7 @@ MPMPF =3D \
prmci6.c \
prmcix.c \
prmclii6.c \
- protix.c \
+ protli.c \
protsgix.c \
pthrdext.c \
span.c \
diff --git a/mps/code/lii6ll.gmk b/mps/code/lii6ll.gmk
index cf3e70ace07..b51ed1895b9 100644
--- a/mps/code/lii6ll.gmk
+++ b/mps/code/lii6ll.gmk
@@ -12,7 +12,7 @@ MPMPF =3D \
prmci6.c \
prmcix.c \
prmclii6.c \
- protix.c \
+ protli.c \
protsgix.c \
pthrdext.c \
span.c \
diff --git a/mps/code/mps.c b/mps/code/mps.c
index d9485c17e86..01033229d13 100644
--- a/mps/code/mps.c
+++ b/mps/code/mps.c
@@ -191,7 +191,7 @@
#include "thix.c" /* Posix threading */
#include "pthrdext.c" /* Posix thread extensions */
#include "vmix.c" /* Posix virtual memory */
-#include "protix.c" /* Posix protection */
+#include "protli.c" /* Linux protection */
#include "protsgix.c" /* Posix signal handling */
#include "prmcanan.c" /* generic architecture mutator context */
#include "prmcix.c" /* Posix mutator context */
@@ -206,7 +206,7 @@
#include "thix.c" /* Posix threading */
#include "pthrdext.c" /* Posix thread extensions */
#include "vmix.c" /* Posix virtual memory */
-#include "protix.c" /* Posix protection */
+#include "protli.c" /* Linux protection */
#include "protsgix.c" /* Posix signal handling */
#include "prmci3.c" /* IA-32 mutator context */
#include "prmcix.c" /* Posix mutator context */
@@ -221,7 +221,7 @@
#include "thix.c" /* Posix threading */
#include "pthrdext.c" /* Posix thread extensions */
#include "vmix.c" /* Posix virtual memory */
-#include "protix.c" /* Posix protection */
+#include "protli.c" /* Linux protection */
#include "protsgix.c" /* Posix signal handling */
#include "prmci6.c" /* x86-64 mutator context */
#include "prmcix.c" /* Posix mutator context */
diff --git a/mps/code/protli.c b/mps/code/protli.c
new file mode 100644
index 00000000000..1f2d5092486
--- /dev/null
+++ b/mps/code/protli.c
@@ -0,0 +1,252 @@
+/* protli.c: PROTECTION FOR LINUX
+ *
+ * $Id$
+ * Copyright (c) 2001-2020 Ravenbrook Limited. See end of file for licen=
se.
+ *
+ * Specific to Linux, which limits the number of VM maps to 65530 by defa=
ult.
+ *
+ *
+ * SOURCES
+ *
+ * [SUSV2MPROTECT] Single UNIX Specification, Version 2, mprotect
+ * <https://pubs.opengroup.org/onlinepubs/007908799/xsh/mprotect.html>
+ *
+ * ASSUMPTIONS
+ *
+ * .assume.mprotect.base: We assume that the first argument to mprotect c=
an
+ * be safely passed as a void *. Single UNIX Specification Version 2 (a=
ka
+ * X/OPEN XSH5) says that the parameter is a void *. Some Unix-likes ma=
y
+ * declare this parameter as a caddr_t. FreeBSD used to do this (on the=
now
+ * very obsolete FreeBSD 2.2.x series), as did macOS, but both now impl=
ement
+ * it correctly as void *. caddr_t is usually char *.
+ *
+ * .assume.write-only: More of an anti-assumption really. We
+ * assume that asking the OS for a write-only page (that is, flags =3D
+ * PROT_WRITE) does not work. What actually happens on all the
+ * Unix-like OSes that we've seen is that asking for write-permission
+ * (flags =3D PROT_WRITE) grants read-permission as well. That is why
+ * when the MPS requires that a page be read-protected (mode =3D=3D
+ * AccessREAD) we must ensure that writes are also not allowed.
+ * The portable guarantees of mprotect (see [SUSV2MPROTECT]) are that
+ * writes are not permitted where PROT_WRITE is not used and no access
+ * is permitted when PROT_NONE alone is used.
+ */
+
+#include "mpm.h"
+
+#if !defined(MPS_OS_LI)
+#error "protli.c is specific to MPS_OS_LI"
+#endif
+
+#include "vm.h"
+
+#include <errno.h>
+#include <limits.h>
+#include <signal.h> /* sig_atomic_t */
+#include <stddef.h>
+#include <sys/mman.h>
+#include <sys/types.h>
+
+SRCID(protli, "$Id$");
+
+
+/* Value for memory protection corresponding to AccessSetEMPTY.
+ * See .convert.access for an explanation of the conversion.
+ * We use a global variable and not a constant so that we can clear
+ * the executable flag from future requests if Apple Hardened Runtime
+ * is detected. See <design/prot#impl.xc.prot.exec> for details. */
+
+static sig_atomic_t prot_all =3D PROT_READ | PROT_WRITE | PROT_EXEC;
+
+/* Too many mprotected regions: don't install further read/write
+ barriers, and do a full synchronization in the next ProtSync. */
+static bool mprotect_overflow;
+
+/* Number of remaining mprotect calls until we check the maps count
+ again. */
+static ptrdiff_t mprotect_budget;
+
+/* Count the number of vm maps of the current process. */
+static ptrdiff_t count_maps (void)
+{
+ ptrdiff_t ret =3D 0;
+ FILE *f =3D fopen ("/proc/self/maps", "r");
+ int c;
+ if (f =3D=3D NULL)
+ return 0;
+ while ((c =3D getc (f)) !=3D EOF)
+ ret +=3D c =3D=3D '\n';
+ fclose (f);
+ return ret;
+}
+
+static ptrdiff_t max_maps (void)
+{
+ FILE *f =3D fopen ("/proc/sys/vm/max_map_count", "r");
+ int c;
+ if (f =3D=3D NULL)
+ return 65530;
+ long maps;
+ if (fscanf (f, "%ld", &maps) !=3D 1) {
+ fclose (f);
+ return 65530;
+ }
+ fclose (f);
+ return maps;
+}
+
+/* ProtSet -- set protection
+ *
+ * This is just a thin veneer on top of mprotect(2).
+ */
+
+void ProtSet(Addr base, Addr limit, AccessSet mode)
+{
+ int flags, result;
+
+ AVER(sizeof(size_t) =3D=3D sizeof(Addr));
+ AVER(base < limit);
+ AVER(base !=3D 0);
+ AVER(AddrOffset(base, limit) <=3D INT_MAX); /* should be redundant *=
/
+ AVERT(AccessSet, mode);
+
+ /* .convert.access: Convert between MPS AccessSet and UNIX PROT thingies=
.
+ In this function, AccessREAD means protect against read accesses
+ (disallow them). PROT_READ means allow read accesses. Notice that
+ this follows a difference in contract as well as style. AccessREAD
+ means that no reads should be permitted (all reads should go via
+ the signal handler), possibly other operations (write) also go via
+ the signal handler; PROT_WRITE means that all writes should be
+ allowed, possibly that means other operations (read) are also
+ allowed.
+ */
+ switch(mode) {
+ case AccessWRITE | AccessREAD:
+ case AccessREAD: /* forbids writes as well, see .assume.write-only =
*/
+ flags =3D PROT_NONE;
+ break;
+ case AccessWRITE:
+ flags =3D PROT_READ | PROT_EXEC;
+ break;
+ case AccessSetEMPTY:
+ flags =3D (int)prot_all; /* potential narrowing cast, but safe */
+ break;
+ default:
+ NOTREACHED;
+ flags =3D PROT_NONE;
+ }
+
+ /* Too many protected regions? */
+ if (mprotect_budget-- <=3D 0) {
+ ptrdiff_t count =3D count_maps ();
+ ptrdiff_t max =3D max_maps ();
+ ptrdiff_t slack =3D 1024;
+ mprotect_budget =3D (max - count)/2;
+ if (mprotect_budget < slack) {
+ mprotect_overflow =3D TRUE;
+ }
+ }
+
+ /* When in mprotect overflow mode, remove barriers but never install
+ them. */
+ if (mprotect_overflow && flags !=3D prot_all) {
+ /* At this point, we should stop all mutator threads until we hit
+ ProtSync. Does this already happen? */
+ return;
+ }
+
+ /* .assume.mprotect.base */
+ result =3D mprotect((void *)base, (size_t)AddrOffset(base, limit), flags=
);
+ if (MAYBE_HARDENED_RUNTIME && result !=3D 0 && errno =3D=3D EACCES
+ && (flags & PROT_WRITE) && (flags & PROT_EXEC))
+ {
+ /* Apple Hardened Runtime is enabled, so that we cannot have
+ * memory that is simultaneously writable and executable. Handle
+ * this by dropping the executable part of the request. See
+ * <design/prot#impl.xc.prot.exec> for details. */
+ prot_all =3D PROT_READ | PROT_WRITE;
+ result =3D mprotect((void *)base, (size_t)AddrOffset(base, limit), fla=
gs & prot_all);
+ }
+ if (result !=3D 0)
+ NOTREACHED;
+}
+
+
+/* ProtSync -- synchronize protection settings with hardware
+ *
+ * This only does something if we ran out of mprotect calls.
+ */
+
+void ProtSync(Arena arena)
+{
+ if (!mprotect_overflow)
+ return;
+
+ mprotect_overflow =3D FALSE;
+
+ TraceId ti;
+ TraceSet ts =3D TraceSetUnion (arena->busyTraces, arena->flippedTraces);
+ Trace trace;
+ TRACE_SET_ITER (ti, trace, ts, arena)
+ TracePostAbortMessage (trace, TraceAbortWhyMPROTECT_LIMIT);
+ TRACE_SET_ITER_END (ti, trace, ts, arena);
+
+ bool synced;
+
+ AVERT(Arena, arena);
+
+ do {
+ Seg seg;
+
+ synced =3D TRUE;
+ if (SegFirst(&seg, arena)) {
+ do {
+ if (SegPM(seg) !=3D AccessSetEMPTY) { /* <design/protan#.fun.sync.=
seg> */
+ ShieldEnter(arena);
+ TraceSegAccess(arena, seg, SegPM(seg));
+ ShieldLeave(arena);
+ synced =3D FALSE;
+ }
+ } while(SegNext(&seg, arena, seg));
+ }
+ } while(!synced);
+}
+
+
+/* ProtGranularity -- return the granularity of protection */
+
+Size ProtGranularity(void)
+{
+ /* Individual pages can be protected. */
+ return PageSize();
+}
+
+
+/* C. COPYRIGHT AND LICENSE
+ *
+ * Copyright (C) 2001-2020 Ravenbrook Limited <https://www.ravenbrook.com/=
>.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+ * IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+ * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
--=20
2.53.0
From a4f0ff72e5a25c25da6a5e0138ad5562600599f0 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Sun, 5 Apr 2026 11:08:11 +0000
Subject: [PATCH 3/3] [MPS] Enable and report GC abort messages
As these are extraordinary messages worthy of the user's attention, we
display them even if garbage_collection_messages is false.
* src/igc.c (process_one_message):
(enable_messages): Handle GC abort messages.
---
src/igc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/igc.c b/src/igc.c
index 88d2aaf2f6d..abafb00e3f2 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -4671,6 +4671,17 @@ process_one_message (struct igc *gc)
=09 message ("[%f] GC start: %s", secs, why);
=09}
}
+ else if (type =3D=3D mps_message_type_gc_abort ())
+ {
+ if (garbage_collection_messages
+=09 || !noninteractive)
+=09{
+=09 mps_clock_t clock =3D mps_message_clock (gc->arena, msg);
+=09 const char *why =3D mps_message_gc_abort_why (gc->arena, msg);
+=09 double secs =3D (double) clock / mps_clocks_per_sec ();
+=09 message ("[%f] GC abort: %s", secs, why);
+=09}
+ }
else if (type =3D=3D mps_message_type_gc ())
{
if (garbage_collection_messages)
@@ -4701,6 +4712,7 @@ enable_messages (struct igc *gc, bool enable)
=3D enable ? mps_message_type_enable : mps_message_type_disable;
fun (gc->arena, mps_message_type_finalization ());
fun (gc->arena, mps_message_type_gc_start ());
+ fun (gc->arena, mps_message_type_gc_abort ());
fun (gc->arena, mps_message_type_gc ());
}
=20
--=20
2.53.0
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 5 Apr 2026 09:45:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 05 05:45:29 2026 Received: from localhost ([127.0.0.1]:56115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w9K2q-0002wC-KC for submit <at> debbugs.gnu.org; Sun, 05 Apr 2026 05:45:29 -0400 Received: from mail-244123.protonmail.ch ([109.224.244.123]:21455) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1w9K2o-0002vg-9n for 80712 <at> debbugs.gnu.org; Sun, 05 Apr 2026 05:45:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1775382317; x=1775641517; bh=QCG9pTdJYpjuYth67spfz63TvY48Du5F8/YExWt+Cbw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fTSzjk0IbFMQGNN9IYlWoXEVKASvmwHim/Urtr0pMUpJ9KEtwrGi2IwpAlpz+CG/t upF21DtftTvouIoCFxnQ0qrBR5bLlYQcmx088ix6IhNdj4vlbbl1PHvWAoZHxEmLti 3hVvdq8yiidfv2bXrY08DItTUCd8N6bM2QGIiA1n1WyMW7ElDYZHXXfXYIangBIQ4E Kwk67nO/LUQR9N61hlcsYydo5ClDmvuEMkB45pp/pXXcvZf7atDtF4wN1bRG8d0r0i aqUNE+twAdyYUC/5/5DxsfHu3lHkQd0aApqO6QUiX9fruUONkMFWejAOhNClljteBQ ZmPogGHjy6vOQ== Date: Sun, 05 Apr 2026 09:45:13 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR Message-ID: <874ilpwxiw.fsf@HIDDEN> In-Reply-To: <87jyulkclh.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN> <87qzoujymy.fsf@HIDDEN> <87a4viwkxe.fsf@HIDDEN> <87jyulkclh.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e6724c378cce37d9221e055bc031aa46e4b9253d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) "Helmut Eller" <eller.helmut@HIDDEN> writes: > On Sat, Apr 04 2026, Pip Cet wrote: > >> "Helmut Eller" <eller.helmut@HIDDEN> writes: >> >>>> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001 >>>> From: Pip Cet <pipcet@HIDDEN> >>>> Date: Sat, 4 Apr 2026 17:16:38 +0000 >>>> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705= , >>>> bug#80712) >>>> >>>> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New >>>> variables. >>>> (count_maps): New. >>>> (ProtSet): Avoid unbounded mprotect calls. >>>> (ProtSync): Clean up after potentially skipping mprotect calls. >>> >>> So the basic idea is: if mprotect fails, then ProtSet becomes a noop an= d >>> ProtSync will be used instead? >> >> No. >> >> First, we should never let mprotect fail: if it does, we've exhausted >> all maps, and other code might try an mmap (or malloc) and fail, or >> already have done so. So we use a "budget" instead, chosen so that even >> in the worst case, the number of maps won't reach MAGIC NUMBER (6000 for >> testing, 60000 for production). >> >> ProtSet doesn't become a noop: we still need it to remove barriers, but >> we'll refuse to install new ones. >> >> And ProtSync forcibly triggers all memory barriers after an emergency >> (it's taken from protan.c), which will hopefully reduce the number of >> maps so much that the next emergency won't be just around the corner. > > OK. I see no reason why this wouldn't work. This should be tested > however. I agree, and that's why the numbers chosen were so low: I found it kind of difficult to hit the 65530 limit reliably (not that I've tried very hard). It seems to behave as expected, though, so could you clarify what kind of tests should be run before we can consider pushing this? >>> 3. when Emacs sees the "out-of-mappings" message it calls memory_full >> >> Why? Wouldn't a message and carrying on be the best course of action? > > That's probably better, yes. Of course if it turns out that the "hopefully" above isn't realistic (and we run into the limit over and over again, essentially making us a mark-and-sweep allocator), we can always do the memory_full thing. (As for memory protection keys, I still have that patch around somewhere to make MPS use them, but I think it's low priority, and only really useful with a background thread (which would scan memory areas that are behind barriers for the mutator threads). However, note that the Linux kernel developers messed up when determining the interaction of signal handlers and protection keys, so that's a headache.) Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 5 Apr 2026 09:13:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 05 05:13:01 2026 Received: from localhost ([127.0.0.1]:55825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w9JXQ-00085Y-6Q for submit <at> debbugs.gnu.org; Sun, 05 Apr 2026 05:13:01 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:51464) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1w9JXN-000850-Nc for 80712 <at> debbugs.gnu.org; Sun, 05 Apr 2026 05:12:58 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-48558d6ef83so31136895e9.3 for <80712 <at> debbugs.gnu.org>; Sun, 05 Apr 2026 02:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775380376; x=1775985176; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=uXkN54ljuYHXX01nXjPI/tQoHB20dKqpGlQY9+Sgot8=; b=sK8u1hN+kCBbw4HnYCPYzywXZtbglszgKNzR6sNAQh4ehKUEMrTFhKdVlLSJqpiVFA v5Qzv8qYvhxH17zX1NTb5dE7DqVjIdKoJcq6mhTfRnnAkbdExgCNZ3cK4vjQvXNcmff0 Mu/Weyx7O5fuS7adncM8kKi7plMthhl18X0aKnCygbJPnv57nDjegR3WDK6/rF4cPLMh l0sir4/uPZ1VrZ6lZ7ol3cS3e4V6I4qQjgN/q7LtgqzPN/Ei+/tnrcBPK8dRyGa5Qf7V rJ54GRq7UxD94PNcVhTQMr9rDgB8EXSPybBaDTy93PwakBT+3B2jYjK4U2iukCCryO+U uaOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775380376; x=1775985176; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=uXkN54ljuYHXX01nXjPI/tQoHB20dKqpGlQY9+Sgot8=; b=atZBYBoT4cxmB0nBLazaU+B4l2qnQPGmInYbs11gD1Iz3aQXkkXJRdXPROeEt2G/s+ TjGnZXpa0Wvgan7ClFyapGXWPLChFK0VElaIqmSUULCgvaJ2cYxAKW52+BeWGOJvSHT0 SLDrmrFqk2WCpd8RjbnTdwXB7nki887HHRJ/5zXHtnIHiLhvKD4kLiVvdtAOpR03JR1h MIF9gBdW9Yts7b30oN0tKiaSPJnPTr0qQ8ecNFXKkTZ905wktFaS5fh3o6ugiBShQHVE y8VR0/6cIuu2LQfyJHO/C802tL93BTyClOm8uCwvdbIgxTuHG+8eG2nDUujqOn8C2Otm GUlw== X-Forwarded-Encrypted: i=1; AJvYcCUXZ0TLtYDCNwnpaLkLJimwIOrWvK43mdMbK0Jk1DyJHxc8/JdPHmMuWBVpBqbNyOwxw2rIFw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwFhJgKwQOO2/0TobBDcvUrJs1mg/cQgj5fD1QQxXYBeBrtUgXO 2S8JdKAF7Maa8/uFErblVS0pegkck/I4bHft4OzRCF/QIkE1XA+yEdwd X-Gm-Gg: AeBDieuRe0jMqk01//v6dtP1oKZEVHECS87D9c0C5uKp1pFPVEFJETNYcstGlewzTeO DC3G0HPROn71zTZVbIm+dwSiQuwGxKV/Mznv3uHEO+/HC80uV7tS4raKLcDoa89qizXwliC/0hO NK4GnnhCc9PAWFoC+1+HsdP2W4H+HjZdf0xcg+2RFhJYGZwU7G8bzgXloUHW3NMPLLrK6MMj74s Jd15uaf8ASVGWq+jrHfR+Tve2dP1oA/mBcST3FHAfRAVl7MlBNTeHWxvMtqkJGdalmzETyou3jo OY39dSh38AWV6W3v21ejBvEWieBkQ/xXuXcyY8nav8c1RcFdouQQkOKD55Ma+ksoOW8TktgfUyC 4F8VvjTbuRkkwP5bdTi4gBYrVAwFctdC0FE712S/beweiCVC/PnPoNpihhajLa0WZl8VYxbEcA4 t1cg4kNj8BF6zmjqJ8sQ== X-Received: by 2002:a05:600c:638e:b0:487:575:5e1 with SMTP id 5b1f17b1804b1-488997adbbcmr130806405e9.24.1775380376236; Sun, 05 Apr 2026 02:12:56 -0700 (PDT) Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e80a616sm680494015e9.2.2026.04.05.02.12.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2026 02:12:55 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <86bjfy2cfv.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN> <87qzoujymy.fsf@HIDDEN> <86bjfy2cfv.fsf@HIDDEN> Date: Sun, 05 Apr 2026 11:12:55 +0200 Message-ID: <875x65kbxk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, pipcet@HIDDEN, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) On Sun, Apr 05 2026, Eli Zaretskii wrote: [...] > Btw, any idea why MPS runs into this limitation of Linux? Only Linux seems to have a limit on the number of mappings. It is so low because the 32-bit core format couldn't represent more. When switching to 64-bit, they left it the same to give tools time to adjust. > I'm > guessing no other important application does, since otherwise the > Linux developers would have raised the limit long ago. Most other GCs use software memory barriers and hardware memory barriers are indeed out of fashion. Hardware memory barriers are however used by some databases and presumably virtualization software; at least the userfaultfd syscall seems to be intended for migration virtual machines. I guess in those uses cases, adjusting the limit manually is not much of problem. It could be that with the wider availability of memory protection key, hardware memory barriers become more popular again. We'll see. Helmut
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 5 Apr 2026 08:58:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 05 04:58:42 2026 Received: from localhost ([127.0.0.1]:55682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w9JJZ-0006yo-6m for submit <at> debbugs.gnu.org; Sun, 05 Apr 2026 04:58:42 -0400 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:48134) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1w9JJW-0006yE-BO for 80712 <at> debbugs.gnu.org; Sun, 05 Apr 2026 04:58:39 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-488a4bc360bso4809975e9.0 for <80712 <at> debbugs.gnu.org>; Sun, 05 Apr 2026 01:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775379517; x=1775984317; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=jCWAzHPvL4GNTEUoJn+4FtA0kzm2PgD5LhtsnhFOywE=; b=OAx8Q0gzoW7/bUgSwYeSihtFLs1EZMsGnZfq2xkP3o/WaP99mETM6tSdPaRZDF2oaV pe+Y9evt6Z0QvZCHGnsh2w13shyLhGHHSXQQVHlHnqbUZdeq5hsN3veBq+gnWc9T1wzQ OS4E3CPNm6nPHP1Zh+d1bClLLBpyx7yzcEl46kxW5arNNzsjCm3uSb7HkCFfHhX/OlfP 92j7SgT4ekkYDDeczbnOjcUl5cy2HNJlz0mziZxbfK7k7rX0i47VIytigd0CdRfmcft6 /waAgXt00uUhxYcE8JKvKJJtB6mJXQmRoXannEcgAUXztkijApLP0U2Q8sx/9MeiGAIN aoHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775379517; x=1775984317; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=jCWAzHPvL4GNTEUoJn+4FtA0kzm2PgD5LhtsnhFOywE=; b=hyUOWMTCS0onmaKlx+6d8nZ0/TlZlJzIZjy+t4f6gu+5ScSmM0JLKJgomvsC0uxVif JUSpTXQTLkstEL4HVFIa78PCcQgXn9EI+mNGwBHGXw37jbl/wMkl7pKxh/SiELMa5C65 ao8UttKEl+dgIE+43BqPTeUiWhCk0+REciXYRziw1V8aHqYB3Vi9l0TSJjkcldxgzULI XsBAYcF/kvQ+uaUA07dta9pJLV7VXFFWyZNIej30l3HlTbWDlP18IKU+XLe/xGadeh99 EDKqI9q4rv0MU4+4rbIFTWsHXVTrlNOhjgu1Vgx+VA2a8leEHLxa65Imvtt8Jr8Z8q5E Vnzg== X-Forwarded-Encrypted: i=1; AJvYcCXcqgsU4EEQyKMVqEeonUuTYludV0wj8Y3xjzMUzUsYfNTeOXCrVRLFS8XMYEecbQiX74iTRw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzbpDJGr+l6hB8zBGloeDTZC14v4oVurpAtio2lv5HL8/NSKr6S DdKWK2/1aWgss8baJSSZKMvhnOe448dMAOqSH7vfTKP0QD6X6yGrsuXc X-Gm-Gg: AeBDiet2TPEI9VAwPsQRBw2kGOKlE0O2sty1BZ5hgjvsF/31Mnllqxy6WGFWPr9NmvW nmUby9M28elnHHw/zkd8ukRKGKhoyMLbHtf6ZysGfLHhs9557LnxOnqwGVkUZy6Fr4q2ORLUlWI FfsMh2t6CZEKQ+JxRjRGJP+cAleOGArwdvnVWTIt4Q8mSNh2iIA2oc3+u/mTpApH5v695lJTGyr doPCEcJ00lM8bAKza8Fk1nhGWMRnfln4vYAnErcGBnXBMHCLLHyDjHsD5wVbxo8xsRWqEesihY4 0M3oiexe8HK9w18i1ekbPw+yyTsoY/mQHkn3bC2hlMmur5cPqdr23Xkbi0d4ZPhOi/bvV9c3uQu TbdDdY1cWgdALm9cwFw2DuP20dT12mJHpAe0LFUi5Y+npECNDmX6xIC+jZp0EXVXhbbCUXgpP27 PIU+n9SvEpToMRA7Uv+w== X-Received: by 2002:a05:600c:64ce:b0:487:338:b4eb with SMTP id 5b1f17b1804b1-488997c820amr111585355e9.28.1775379516998; Sun, 05 Apr 2026 01:58:36 -0700 (PDT) Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e80a616sm679147225e9.2.2026.04.05.01.58.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2026 01:58:35 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <87a4viwkxe.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN> <87qzoujymy.fsf@HIDDEN> <87a4viwkxe.fsf@HIDDEN> Date: Sun, 05 Apr 2026 10:58:34 +0200 Message-ID: <87jyulkclh.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) On Sat, Apr 04 2026, Pip Cet wrote: > "Helmut Eller" <eller.helmut@HIDDEN> writes: > >>> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001 >>> From: Pip Cet <pipcet@HIDDEN> >>> Date: Sat, 4 Apr 2026 17:16:38 +0000 >>> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705, >>> bug#80712) >>> >>> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New >>> variables. >>> (count_maps): New. >>> (ProtSet): Avoid unbounded mprotect calls. >>> (ProtSync): Clean up after potentially skipping mprotect calls. >> >> So the basic idea is: if mprotect fails, then ProtSet becomes a noop and >> ProtSync will be used instead? > > No. > > First, we should never let mprotect fail: if it does, we've exhausted > all maps, and other code might try an mmap (or malloc) and fail, or > already have done so. So we use a "budget" instead, chosen so that even > in the worst case, the number of maps won't reach MAGIC NUMBER (6000 for > testing, 60000 for production). > > ProtSet doesn't become a noop: we still need it to remove barriers, but > we'll refuse to install new ones. > > And ProtSync forcibly triggers all memory barriers after an emergency > (it's taken from protan.c), which will hopefully reduce the number of > maps so much that the next emergency won't be just around the corner. OK. I see no reason why this wouldn't work. This should be tested however. >> I wonder if we could: >> >> 1. reserve some extra mappings > > My approach doesn't need to: when we get close to the limit, we stop > installing new memory barriers. > >> 2. if mprotect fails >> a. put a "out-of-mappings" message in the message queue >> b. release the reserved mappings >> c. retry mprotect hoping that it now succeeds > > mprotect should never be allowed to fail. We should do (a) (not in the > poc), we should release maps as soon as it's safe again (which should be > the next ProtSync), and we can't do (c), I think. > >> 3. when Emacs sees the "out-of-mappings" message it calls memory_full > > Why? Wouldn't a message and carrying on be the best course of action? That's probably better, yes. Helmut
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 5 Apr 2026 05:39:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 05 01:39:27 2026 Received: from localhost ([127.0.0.1]:54073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w9GCl-0005m2-1s for submit <at> debbugs.gnu.org; Sun, 05 Apr 2026 01:39:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40272) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w9GCj-0005lm-5X for 80712 <at> debbugs.gnu.org; Sun, 05 Apr 2026 01:39:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w9GCd-00041L-Mf; Sun, 05 Apr 2026 01:39:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=f6PKuHq8+EtLEUhHT92xuwlbjv0xC4yJy30ASejQxf8=; b=IpOM1Ry0nko7 EBfGzoe6FyOV3tFUMalUwegDpAUZPNxDaLIJfi1YAxALenJ1mja3tgnX6j7ZjPYusuzDYxwMSgZ0R IWRkgvKF+WPhikkgKkM+cfq6CWHsE8G4opb1huLf/ZusCsZm08y4Q2e+expH1O6otJ+5Iqbv/nRJ1 s0a+E1vpfTVwMDRO9jrrvp8HGkGCK9x6IwIiMo6UCJGWu6gcBUXeVMChZnb1mDcqv5w5wxIKa+03Z KEJvUI27SLXIoum9WavggLuB2jxG22C6p0JgJC0DVKpCzlTYkjcHvHZ0lMEr24F5uZFg0K5/MYqUO aiSAY9ZrvLJ3S0wKIgp36A==; Date: Sun, 05 Apr 2026 08:39:16 +0300 Message-Id: <86bjfy2cfv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN> In-Reply-To: <87qzoujymy.fsf@HIDDEN> (message from Helmut Eller on Sat, 04 Apr 2026 21:47:49 +0200) Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN> <87qzoujymy.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, pipcet@HIDDEN, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Helmut Eller <eller.helmut@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80712 <at> debbugs.gnu.org, yantar92@HIDDEN > Date: Sat, 04 Apr 2026 21:47:49 +0200 > > I wonder if we could: > > 1. reserve some extra mappings > 2. if mprotect fails > a. put a "out-of-mappings" message in the message queue > b. release the reserved mappings > c. retry mprotect hoping that it now succeeds > 3. when Emacs sees the "out-of-mappings" message it calls memory_full That's basically what we used to do with the old GC, including reserving some memory in advance (because handling the memory-full signal and then shutting down the session in an orderly fashion generally needs some memory to work with). So yes, I think something like this would be very useful. Btw, any idea why MPS runs into this limitation of Linux? I'm guessing no other important application does, since otherwise the Linux developers would have raised the limit long ago.
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 4 Apr 2026 20:05:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 16:05:16 2026 Received: from localhost ([127.0.0.1]:48823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w97F6-0001uG-55 for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 16:05:16 -0400 Received: from mail-244122.protonmail.ch ([109.224.244.122]:54931) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1w97F2-0001oJ-Pz for 80712 <at> debbugs.gnu.org; Sat, 04 Apr 2026 16:05:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1775333106; x=1775592306; bh=oi2DG+0DV9Laa7fiKqQ9VAhl1y1CranP4c3fru0RXCk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Z92bMhWsLUdeGxfSvyipG0PfWD1ZO/PQrkxMSC3LAs4tHyRg956LfUK9cuoqNoW75 d7bFumIrx3zgJ2AaOsMqn3O9BTACc3WUFaOUUqS6nggu7V6Kr/0fJZ7GZOx6g3lFHc e4R+jgQ2veLYg3MumzadvKkRoiyqjJLaQ3z1LXfu8ct96I2bNuEB/AfXcmWgeku8Bw fZ/Ju75b9eY4jyUJOf54sSjlbNDLTMt01rVKBJji0uZSOIbbXrJtNzq71ShV9mLdu6 Ee0odb2kHIS4OUdfP7TLSnYdFHHuW+9aNKlXkBNSsI3tfpTd8DlQwpvPq1plM9R38q 5rivwe07ddH1w== Date: Sat, 04 Apr 2026 20:05:02 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR Message-ID: <87a4viwkxe.fsf@HIDDEN> In-Reply-To: <87qzoujymy.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN> <87fr5awrsb.fsf@HIDDEN> <87qzoujymy.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 00f501f2a076bfe76c5c58f1fae9b8172db1459d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) "Helmut Eller" <eller.helmut@HIDDEN> writes: >> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Sat, 4 Apr 2026 17:16:38 +0000 >> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705, >> bug#80712) >> >> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New >> variables. >> (count_maps): New. >> (ProtSet): Avoid unbounded mprotect calls. >> (ProtSync): Clean up after potentially skipping mprotect calls. > > So the basic idea is: if mprotect fails, then ProtSet becomes a noop and > ProtSync will be used instead? No. First, we should never let mprotect fail: if it does, we've exhausted all maps, and other code might try an mmap (or malloc) and fail, or already have done so. So we use a "budget" instead, chosen so that even in the worst case, the number of maps won't reach MAGIC NUMBER (6000 for testing, 60000 for production). ProtSet doesn't become a noop: we still need it to remove barriers, but we'll refuse to install new ones. And ProtSync forcibly triggers all memory barriers after an emergency (it's taken from protan.c), which will hopefully reduce the number of maps so much that the next emergency won't be just around the corner. > I wonder if we could: > > 1. reserve some extra mappings My approach doesn't need to: when we get close to the limit, we stop installing new memory barriers. > 2. if mprotect fails > a. put a "out-of-mappings" message in the message queue > b. release the reserved mappings > c. retry mprotect hoping that it now succeeds mprotect should never be allowed to fail. We should do (a) (not in the poc), we should release maps as soon as it's safe again (which should be the next ProtSync), and we can't do (c), I think. > 3. when Emacs sees the "out-of-mappings" message it calls memory_full Why? Wouldn't a message and carrying on be the best course of action? I'm not entirely sure whether moving the code from ProtSync to ProtSet would be safe, so I didn't. Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at 80712) by debbugs.gnu.org; 4 Apr 2026 19:47:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 15:47:56 2026
Received: from localhost ([127.0.0.1]:48697 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w96yJ-0000vg-R5
for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 15:47:56 -0400
Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:51286)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1w96yH-0000vW-1u
for 80712 <at> debbugs.gnu.org; Sat, 04 Apr 2026 15:47:53 -0400
Received: by mail-wr1-x430.google.com with SMTP id
ffacd0b85a97d-43cfb723793so1754146f8f.2
for <80712 <at> debbugs.gnu.org>; Sat, 04 Apr 2026 12:47:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1775332071; x=1775936871; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=5zNY2kd+R08IlnBmGeUO9+Uf04JX4DUExObrDLN4z3Y=;
b=XAUtA63SLMgRflRL7i51ce4Fq3H0WTx6H8LA97QmtDq8nXsUiU6RKscbhD6U+qeXKl
C8LeMooWkU51qwkTTizBK94rigbwqEF3T/K+Z9R1jT2qapoXmuk5+siz/uClPe6QAgd0
UzirCR7pJRTKm3f6c//vphpRrhAstZXvMp6xcvlbtw0a+lXB9otW40uQmSwJ4YR4RXnX
JNwmxCHnqOiQlExJaD53Lfl3YKLxIOjDBbNy0qCFokFJy6jAYZTdKgWeOJR9iSppIpXl
OTZamqIXxzdUWvyJnCo2iTNzU4sCVnpg9lrxfV9VJFqLFEvJKcOfKfJ1lyzG/JrfY6qC
RwTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1775332071; x=1775936871;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=5zNY2kd+R08IlnBmGeUO9+Uf04JX4DUExObrDLN4z3Y=;
b=Vi42ie6I33tnSY8sDj5v4Pepr9ebpkEY3szkI3RuzICHIZoCA6Ov6oxOsQtl+4TnSp
ubGXh2DcnC652YusZJYRm6Wt/NLWIbuAhqcb0J2zj2vAtkEZUi3oRwghVcr6u2kPbOt7
6NNsJiILhGNfxWgY/nLopDoUxjugQ9+CzlprBV75Ld6vjr5N8zwA1VTOqDHy5ddCKa6/
UTV8lStf0nocD5d8YvekQvZgGh34OAZ/oGD7EyedkPmOQ8n0LGlbWEUj0pO2qY16RKHT
vAninfgRCzZLqUg4oGoDKlPW4ytPI1TSfzaR6MesRCFhLwlaOIMXnGcKMcKQdHlPE7yM
uM9A==
X-Forwarded-Encrypted: i=1;
AJvYcCV2TJVRDOA0CdMeJZ0joSWeDVHHfoAzbQUHaZAC7PzZSfvuVTIzvN4zLF0dImad9l7p0Unt0g==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzDL3f1YuR+ibVbCVHghmhFKXQG8I4abKBkh4BxwLJeUvhx/HF/
jWz7crqpG6C25w4h+qEK1B2lQ6L6r6z2yRQla6TtYbFoxHUs+HXwTcD+
X-Gm-Gg: AeBDieuIL8ZItN1NHsjE0rboEQFj5MdHT1Wd9aUrh9s6jluGo/XDLGvm+VeBl+i4KVE
x2M0+eWot9ArE3DM0Wm5WCFje2jOR+JIYg2hRzn1qijLhW0o/AznduFcv1CT7/JJHKZwLwB+7vk
K8NmeVG182prZePLzjT1u9fKlA+jwNLHW4JpOHKNBaQ2Fg/cCRQJZ8sb7gxGklDwZyxxrGpweux
I2D5YnkI1fvwa0V6s8H1pkjt1E5/aD8thb/VfcAGZoPyfSwjHHhchWR4m4j4nhsC/eaGq8E+HAF
C3iBafKkEysKZR40rf2gFqBjVYU6e+SfGkzd40BdkYZ95Fn7rJa7z6isPbjQP+mRdqjeJ+UYve7
1liv42VGBauBFexdOMaTJyFHEUfAQ+fRm0KSfA+JH5ytOwrM2xGbTurjCTf55zGGvXgKr8PshOI
8aP+laAMIjXt4k5/vIBQ==
X-Received: by 2002:a05:6000:2902:b0:43c:ef70:d69a with SMTP id
ffacd0b85a97d-43d29309c97mr10978622f8f.50.1775332071339;
Sat, 04 Apr 2026 12:47:51 -0700 (PDT)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-43d1e4e5890sm26512922f8f.31.2026.04.04.12.47.49
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 04 Apr 2026 12:47:50 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
In-Reply-To: <87fr5awrsb.fsf@HIDDEN>
References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN>
<87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN>
<87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN>
<86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN>
<87fr5awrsb.fsf@HIDDEN>
Date: Sat, 04 Apr 2026 21:47:49 +0200
Message-ID: <87qzoujymy.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80712
Cc: 80712 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, yantar92@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
[Sorry for duplicated messages]
On Sat, Apr 04 2026, Pip Cet via "Bug reports for GNU Emacs, the Swiss
army knife of text editors" wrote:
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
>>> Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN
>>> Date: Thu, 02 Apr 2026 14:59:49 +0300
>>> From: Eli Zaretskii <eliz@HIDDEN>
>>>
>>> > Cc: 80712 <at> debbugs.gnu.org
>>> > Date: Wed, 01 Apr 2026 17:37:01 +0000
>>> > From: Pip Cet <pipcet@HIDDEN>
>>> >
>>> > "Ihor Radchenko" <yantar92@HIDDEN> writes:
>>> >
>>> > > Pip Cet <pipcet@HIDDEN> writes:
>>> > >
>>> > >> Can you run
>>> > >>
>>> > >> wc -l /proc/4810/maps
>>> > >>
>>> > >> as well? I don't know which of the maps show up in map_files and which
>>> > >> don't.
>>> > >
>>> > >> wc -l /proc/4810/maps
>>> > > 65531 /proc/4810/maps
>>> > >
>>> > >>>> Also, can you inspect /proc/sys/vm/max_map_count?
>>> > >>>
>>> > >>>> cat /proc/sys/vm/max_map_count
>>> > >>> 65530
>>> >
>>> > So it is the max_map_count thing. Were you doing anything unusual at the
>>> > time?
>>> >
>>> > It might be necessary to increase the arena grain size to avoid running
>>> > into this over and over again, at least when max_map_count is at its
>>> > default setting.
>>>
>>> Can we detect this situation in advance and call memory_full when the
>>> count is close enough to 65530? That should prevent fatal signals and
>>> the real risk of losing the edits.
>>
>> Ping! Is something like this possible/feasible? If so, I think we
>> should implement it, because people are surely bound to bump into this
>> limitation.
>
> Here's a first proof of concept:
>
> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 4 Apr 2026 17:16:38 +0000
> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705,
> bug#80712)
>
> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New
> variables.
> (count_maps): New.
> (ProtSet): Avoid unbounded mprotect calls.
> (ProtSync): Clean up after potentially skipping mprotect calls.
So the basic idea is: if mprotect fails, then ProtSet becomes a noop and
ProtSync will be used instead?
I wonder if we could:
1. reserve some extra mappings
2. if mprotect fails
a. put a "out-of-mappings" message in the message queue
b. release the reserved mappings
c. retry mprotect hoping that it now succeeds
3. when Emacs sees the "out-of-mappings" message it calls memory_full
Helmut
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 4 Apr 2026 19:42:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 15:42:32 2026
Received: from localhost ([127.0.0.1]:48650 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w96t5-0000hE-BO
for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 15:42:31 -0400
Received: from lists.gnu.org ([2001:470:142::17]:38694)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1w96t2-0000fy-24
for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 15:42:30 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1w96sv-0006Vi-SY
for bug-gnu-emacs@HIDDEN; Sat, 04 Apr 2026 15:42:21 -0400
Received: from ciao.gmane.io ([116.202.254.214])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1w96su-0007AK-EE
for bug-gnu-emacs@HIDDEN; Sat, 04 Apr 2026 15:42:21 -0400
Received: from list by ciao.gmane.io with local (Exim 4.92)
(envelope-from <geb-bug-gnu-emacs@HIDDEN>)
id 1w96sr-0008Zc-FU
for bug-gnu-emacs@HIDDEN; Sat, 04 Apr 2026 21:42:17 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bug-gnu-emacs@HIDDEN
From: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
Date: Sat, 04 Apr 2026 21:42:11 +0200
Message-ID: <874ilqldgs.fsf@HIDDEN>
References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN>
<87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN>
<87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN>
<86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN>
<87fr5awrsb.fsf@HIDDEN>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:3a9zvQWL/BW/gxw23FAJa5+5PIg=
Received-SPF: pass client-ip=116.202.254.214;
envelope-from=geb-bug-gnu-emacs@HIDDEN; helo=ciao.gmane.io
X-Spam_score_int: 3
X-Spam_score: 0.3
X-Spam_bar: /
X-Spam_report: (0.3 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001,
FORGED_GMAIL_RCVD=1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.248, NML_ADSP_CUSTOM_MED=0.9,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On Sat, Apr 04 2026, Pip Cet via "Bug reports for GNU Emacs,
the Swiss army knife of text editors" wrote: > "Eli Zaretskii" writes: >
>>> Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN >>> Date: Thu, 02 Apr 2026
14:59:49 +0300 >>> From: Eli Zaretskii >>> >>> > Cc: 80712 <at> debbugs.gnu.org
>>> > Date: Wed [...]
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
mail domains are different
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (eller.helmut[at]gmail.com)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 T_SPF_PERMERROR SPF: test of record failed (permerror)
0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
EnvelopeFrom freemail headers are different
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
On Sat, Apr 04 2026, Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
>>> Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN
>>> Date: Thu, 02 Apr 2026 14:59:49 +0300
>>> From: Eli Zaretskii <eliz@HIDDEN>
>>>
>>> > Cc: 80712 <at> debbugs.gnu.org
>>> > Date: Wed, 01 Apr 2026 17:37:01 +0000
>>> > From: Pip Cet <pipcet@HIDDEN>
>>> >
>>> > "Ihor Radchenko" <yantar92@HIDDEN> writes:
>>> >
>>> > > Pip Cet <pipcet@HIDDEN> writes:
>>> > >
>>> > >> Can you run
>>> > >>
>>> > >> wc -l /proc/4810/maps
>>> > >>
>>> > >> as well? I don't know which of the maps show up in map_files and which
>>> > >> don't.
>>> > >
>>> > >> wc -l /proc/4810/maps
>>> > > 65531 /proc/4810/maps
>>> > >
>>> > >>>> Also, can you inspect /proc/sys/vm/max_map_count?
>>> > >>>
>>> > >>>> cat /proc/sys/vm/max_map_count
>>> > >>> 65530
>>> >
>>> > So it is the max_map_count thing. Were you doing anything unusual at the
>>> > time?
>>> >
>>> > It might be necessary to increase the arena grain size to avoid running
>>> > into this over and over again, at least when max_map_count is at its
>>> > default setting.
>>>
>>> Can we detect this situation in advance and call memory_full when the
>>> count is close enough to 65530? That should prevent fatal signals and
>>> the real risk of losing the edits.
>>
>> Ping! Is something like this possible/feasible? If so, I think we
>> should implement it, because people are surely bound to bump into this
>> limitation.
>
> Here's a first proof of concept:
>
> From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 4 Apr 2026 17:16:38 +0000
> Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705,
> bug#80712)
>
> * mps/code/protix.c (mprotect_budget, mprotect_overflow): New
> variables.
> (count_maps): New.
> (ProtSet): Avoid unbounded mprotect calls.
> (ProtSync): Clean up after potentially skipping mprotect calls.
So the basic idea is: if mprotect fails, then ProtSet becomes a noop and
ProtSync will be used instead?
I wonder if we could:
1. reserve some extra mappings
2. if mprotect fails
a. put a "out-of-mappings" message in the message queue
b. release the reserved mappings
c. retry mprotect hoping that it now succeeds
3. when Emacs sees the "out-of-mappings" message it calls memory_full
Helmut
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at 80712) by debbugs.gnu.org; 4 Apr 2026 18:41:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 14:41:25 2026
Received: from localhost ([127.0.0.1]:48129 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w95vw-0003My-P8
for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 14:41:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54190)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w95vt-0003MI-HZ
for 80712 <at> debbugs.gnu.org; Sat, 04 Apr 2026 14:41:22 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1w95vn-0000H5-VK; Sat, 04 Apr 2026 14:41:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=KNAgKoE/PbRMl5PW9N0I0doB80gnBk4nfYBHxxgq89Y=; b=X7cozsKprYBi
Ad5JtqfkRrDUGi7NsPvHHT/8zAZFAe2a2yVbxsgIw0ltvCav+TZO8nM6L3mjnTn8DWOWNiHQKoZUe
0ffqi4YZt33iibYq25iPJG/W+4xq0G8ZYaVFS8AWo4R5/gulruoim3WckUoW9hsrWqiWjZdVG1WJL
fVMsR46jtlaIfv/bCZwa78OHKUgaYllcFdlUCJQ/zQfd7Kk4f9MxKRTN3Q7QmZ8J+BmdSVacgukJj
XJrHNkcYXa2J5z7VmDjBIKuHryVVXID0M45Q3SfvYYsEyILaUv29q5+uac7HLA2CDaiSfYlH0WQ6u
cH9w49Xw1z96RIkpzWLX6A==;
Date: Sat, 04 Apr 2026 21:41:14 +0300
Message-Id: <86h5pq36wl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87fr5awrsb.fsf@HIDDEN> (message from Pip Cet on Sat, 04
Apr 2026 17:36:56 +0000)
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN>
<87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN>
<87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN>
<86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN>
<87fr5awrsb.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80712
Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN,
Helmut Eller <eller.helmut@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Sat, 04 Apr 2026 17:36:56 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN
>
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
> > Ping! Is something like this possible/feasible? If so, I think we
> > should implement it, because people are surely bound to bump into this
> > limitation.
>
> Here's a first proof of concept:
Thanks.
> + /* Too many protected regions? */
> + if (mprotect_budget-- <= 0) {
> + ptrdiff_t count = count_maps ();
> + mprotect_budget = (6000 - count)/2;
I understand that this number is intended to be larger in the final
version?
> I'm not sure this is thread-safe, because other mutator threads might be
> running, maybe. Also, I'm not convinced that it isn't theoretically
> possible to hit the limit anyway, but I think it's very unlikely in
> practice.
Isn't it better to do this from Emacs? Then the thread-safety problem
goes away, right? And also the handling of the condition, once it's
detected, is much simpler: just call memory_full/
> Note that other code may call mprotect or mmap, so checking the mprotect
> return value isn't good enough.
It's also too late, I think.
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at 80712) by debbugs.gnu.org; 4 Apr 2026 17:37:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 13:37:10 2026
Received: from localhost ([127.0.0.1]:47707 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w94vl-0005Ne-9e
for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 13:37:10 -0400
Received: from mail-106118.protonmail.ch ([79.135.106.118]:19493)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1w94vh-0005Ls-TF
for 80712 <at> debbugs.gnu.org; Sat, 04 Apr 2026 13:37:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1775324219; x=1775583419;
bh=OQREiTF/1WvXZRbUlRAr+8pHlVHdHLZiE4E0R3ceG3E=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=SAvrVxZZ8DI00+tj/kW1JbRHx2jswMA5avvio0B1GSuoXXQPi92TdPtUdRgi1Irr3
wWOvsC8ue8xj6jTWPCXeM2x8nKyDNnkUuh+QYxzK72bpiagSD2x87HADDLh50ICO0F
w/kw0QFbGHPt4wkp46a/ZP8tCBycfqMvuu1NTNb3jyshFmbFbid3uzWX+OaWC2wBaz
nV/tzsqRCkfDh7XrE1hf2Xl8GkyF99pQvfL/U5fXk3CnCtFH9atRM6XUPfMCZQN83O
fAYYsAW4l2YpZ5eMH4IWWAVtw+OKQ7FLbvNYE+dfPpMnmnYKQuf/NClCayUdywwjdf
aHfJ2h+Rjd3Sw==
Date: Sat, 04 Apr 2026 17:36:56 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
Message-ID: <87fr5awrsb.fsf@HIDDEN>
In-Reply-To: <86ldf33vxq.fsf@HIDDEN>
References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN>
<87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN>
<87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN>
<86bjg18te2.fsf@HIDDEN> <86ldf33vxq.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 95a88c31179e8129c3d2428a562a7eb2cc4eacfa
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 80712
Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN
>> Date: Thu, 02 Apr 2026 14:59:49 +0300
>> From: Eli Zaretskii <eliz@HIDDEN>
>>
>> > Cc: 80712 <at> debbugs.gnu.org
>> > Date: Wed, 01 Apr 2026 17:37:01 +0000
>> > From: Pip Cet <pipcet@HIDDEN>
>> >
>> > "Ihor Radchenko" <yantar92@HIDDEN> writes:
>> >
>> > > Pip Cet <pipcet@HIDDEN> writes:
>> > >
>> > >> Can you run
>> > >>
>> > >> wc -l /proc/4810/maps
>> > >>
>> > >> as well? I don't know which of the maps show up in map_files and wh=
ich
>> > >> don't.
>> > >
>> > >> wc -l /proc/4810/maps
>> > > 65531 /proc/4810/maps
>> > >
>> > >>>> Also, can you inspect /proc/sys/vm/max_map_count?
>> > >>>
>> > >>>> cat /proc/sys/vm/max_map_count
>> > >>> 65530
>> >
>> > So it is the max_map_count thing. Were you doing anything unusual at t=
he
>> > time?
>> >
>> > It might be necessary to increase the arena grain size to avoid runnin=
g
>> > into this over and over again, at least when max_map_count is at its
>> > default setting.
>>
>> Can we detect this situation in advance and call memory_full when the
>> count is close enough to 65530? That should prevent fatal signals and
>> the real risk of losing the edits.
>
> Ping! Is something like this possible/feasible? If so, I think we
> should implement it, because people are surely bound to bump into this
> limitation.
Here's a first proof of concept:
From daed7f39c77efad9e19f53cede7b59632b6c5f12 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 4 Apr 2026 17:16:38 +0000
Subject: [PATCH] Avoid running out of VM map areas on Linux (bug#76705,
bug#80712)
* mps/code/protix.c (mprotect_budget, mprotect_overflow): New
variables.
(count_maps): New.
(ProtSet): Avoid unbounded mprotect calls.
(ProtSync): Clean up after potentially skipping mprotect calls.
---
mps/code/protix.c | 62 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/mps/code/protix.c b/mps/code/protix.c
index 18f29430e07..4479b62f117 100644
--- a/mps/code/protix.c
+++ b/mps/code/protix.c
@@ -60,6 +60,25 @@ SRCID(protix, "$Id$");
=20
static sig_atomic_t prot_all =3D PROT_READ | PROT_WRITE | PROT_EXEC;
=20
+/* Too many mprotected regions: don't install further read/write
+ barriers, and do a full synchronization in the next ProtSync. */
+static bool mprotect_overflow;
+
+/* Number of remaining mprotect calls until we check the maps count
+ again. */
+static ptrdiff_t mprotect_budget;
+
+/* Count the number of vm maps of the current process. */
+static ptrdiff_t count_maps (void)
+{
+ ptrdiff_t ret =3D 0;
+ FILE *f =3D fopen ("/proc/self/maps", "r");
+ int c;
+ while ((c =3D getc (f)) !=3D EOF)
+ ret +=3D c =3D=3D '\n';
+ fclose (f);
+ return ret;
+}
=20
/* ProtSet -- set protection
*
@@ -102,6 +121,23 @@ SRCID(protix, "$Id$");
flags =3D PROT_NONE;
}
=20
+ /* Too many protected regions? */
+ if (mprotect_budget-- <=3D 0) {
+ ptrdiff_t count =3D count_maps ();
+ mprotect_budget =3D (6000 - count)/2;
+ if (mprotect_budget < 1000) {
+ mprotect_overflow =3D TRUE;
+ }
+ }
+
+ /* When in mprotect overflow mode, remove barriers but never install
+ them. */
+ if (mprotect_overflow && flags !=3D prot_all) {
+ /* At this point, we should stop all mutator threads until we hit
+ ProtSync. Does this already happen? */
+ return;
+ }
+
/* .assume.mprotect.base */
result =3D mprotect((void *)base, (size_t)AddrOffset(base, limit), flags=
);
if (MAYBE_HARDENED_RUNTIME && result !=3D 0 && errno =3D=3D EACCES
@@ -126,8 +162,30 @@ SRCID(protix, "$Id$");
=20
void ProtSync(Arena arena)
{
- UNUSED(arena);
- NOOP;
+ if (!mprotect_overflow)
+ return;
+
+ mprotect_overflow =3D FALSE;
+
+ Bool synced;
+
+ AVERT(Arena, arena);
+
+ do {
+ Seg seg;
+
+ synced =3D TRUE;
+ if (SegFirst(&seg, arena)) {
+ do {
+ if (SegPM(seg) !=3D AccessSetEMPTY) { /* <design/protan#.fun.sync.=
seg> */
+ ShieldEnter(arena);
+ TraceSegAccess(arena, seg, SegPM(seg));
+ ShieldLeave(arena);
+ synced =3D FALSE;
+ }
+ } while(SegNext(&seg, arena, seg));
+ }
+ } while(!synced);
}
=20
=20
--=20
2.53.0
The magic numbers are deliberately chosen to be much smaller than useful
in production mode: the point is that we never hit 6000 (or 60000)
mappings; when we're at risk of doing so, we skip potentially dangerous
mprotects and clean up when we next hit ProtSync.
I'm not sure this is thread-safe, because other mutator threads might be
running, maybe. Also, I'm not convinced that it isn't theoretically
possible to hit the limit anyway, but I think it's very unlikely in
practice.
Still, a rather long TODO list:
1. move this to protli.c because it's Linux-specific
2. detect whether the max_maps sysctl is already at a sensible value
3. produce a message when we detect this horrible situation and end up
completing the current GC cycle as mark-and-sweep.
It's hard to detect the situation and signal out of memory, and I don't
think it's the best strategy here.
Note that other code may call mprotect or mmap, so checking the mprotect
return value isn't good enough.
Do we want to do something like this?
Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 4 Apr 2026 09:41:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 04 05:41:25 2026 Received: from localhost ([127.0.0.1]:43327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w8xVN-0003dW-Ch for submit <at> debbugs.gnu.org; Sat, 04 Apr 2026 05:41:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50196) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w8xVK-0003dC-D3 for 80712 <at> debbugs.gnu.org; Sat, 04 Apr 2026 05:41:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w8xVF-0008WI-3T; Sat, 04 Apr 2026 05:41:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dpQ1c2G+hUpCda9/dc4T1lSS7+leKPSyulGEwAaGjYE=; b=ERErG7kJKIXR q4yZdJGujkk5SQgyKJxNYaejGRDgSwy7BVA0VmqzIuiSkSHpKkVNAbQJRI/U2dSV8++qvu9FGKANs eL49V/qVCsu06qi/bZyVu+ByLRWg5+JSGLboFgdI2839OBDBPiT/jOK1Klii58N6NWjYHLj1Y2rtO b8jt2MFS9SyYxSTID3XbeNFSCi/+82Idv1DIIuMZgfK+uK9WOzPqkWWivbpXSRqaIwA2bF4nJjTOR AU+/5Z7k0xo9S8vnZoCbi20KbR7C7+1o/f8xPOOeRZO8mx+tzoisLIaXXG3QizODp0004442lNeoZ gBDtgkYWuAvvlBNQ9weP3A==; Date: Sat, 04 Apr 2026 12:40:33 +0300 Message-Id: <86ldf33vxq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: pipcet@HIDDEN In-Reply-To: <86bjg18te2.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 02 Apr 2026 14:59:49 +0300) Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <86bjg18te2.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN > Date: Thu, 02 Apr 2026 14:59:49 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > Cc: 80712 <at> debbugs.gnu.org > > Date: Wed, 01 Apr 2026 17:37:01 +0000 > > From: Pip Cet <pipcet@HIDDEN> > > > > "Ihor Radchenko" <yantar92@HIDDEN> writes: > > > > > Pip Cet <pipcet@HIDDEN> writes: > > > > > >> Can you run > > >> > > >> wc -l /proc/4810/maps > > >> > > >> as well? I don't know which of the maps show up in map_files and which > > >> don't. > > > > > >> wc -l /proc/4810/maps > > > 65531 /proc/4810/maps > > > > > >>>> Also, can you inspect /proc/sys/vm/max_map_count? > > >>> > > >>>> cat /proc/sys/vm/max_map_count > > >>> 65530 > > > > So it is the max_map_count thing. Were you doing anything unusual at the > > time? > > > > It might be necessary to increase the arena grain size to avoid running > > into this over and over again, at least when max_map_count is at its > > default setting. > > Can we detect this situation in advance and call memory_full when the > count is close enough to 65530? That should prevent fatal signals and > the real risk of losing the edits. Ping! Is something like this possible/feasible? If so, I think we should implement it, because people are surely bound to bump into this limitation.
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 2 Apr 2026 18:11:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 02 14:11:02 2026 Received: from localhost ([127.0.0.1]:45826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w8MVS-0007Rr-0v for submit <at> debbugs.gnu.org; Thu, 02 Apr 2026 14:11:02 -0400 Received: from mout02.posteo.de ([185.67.36.66]:56737) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1w8MVQ-0007RL-8L for 80712 <at> debbugs.gnu.org; Thu, 02 Apr 2026 14:11:01 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E5D5B240103 for <80712 <at> debbugs.gnu.org>; Thu, 2 Apr 2026 20:10:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1775153453; bh=mE6fW9rvKCgPK+VaOnVpy/yh0t9EhZavUi9U6oJPaJw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Jweu/fJQgkRaQJfLTkHLdJZPxv1kZ4905oh7z8vKUfS9OheH7my+9Y5afB9OhItu8 ros5HUhfnIM4Wjo7dNKZVews00kQaDNj2ktquKksrAsYCICUgelPD/vNX+futbUnws 48hM6f6XyODecXt/JNqz6vkdpamteUXWLFGeiI3kYOeTD+408A6/3rFbXzRjApeaZ6 OTUFfKEjWRd6T6srRgLHj6tfIo18mrSInrHAX8EdLNQs+M3T2vLQOrNbCtSd6ReNNk b53tmGd3Wj67I9oWg2Mb2HDrshvgJirIB6xZNYt5EtlcPmQc5gKBN5OrbXpXXdLZ0I 5OLPH84WRUZbA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fmqfP0q1bz9rxG; Thu, 2 Apr 2026 20:10:52 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <86a4vl8t9b.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <87341e60mq.fsf@localhost> <86a4vl8t9b.fsf@HIDDEN> Date: Thu, 02 Apr 2026 18:10:53 +0000 Message-ID: <87h5pt44ik.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, pipcet@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: 80712 <at> debbugs.gnu.org >> From: Ihor Radchenko <yantar92@HIDDEN> >> Date: Wed, 01 Apr 2026 17:39:29 +0000 >> >> Pip Cet <pipcet@HIDDEN> writes: >> >> >>>>> cat /proc/sys/vm/max_map_count >> >>>> 65530 >> > >> > So it is the max_map_count thing. Were you doing anything unusual at the >> > time? >> >> Not really. > > Btw, what is the value of errno inside ProtSet? Is that ENOMEM or > something else? Sorry, I have killed that gdb session by now. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 2 Apr 2026 12:03:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 02 08:03:00 2026 Received: from localhost ([127.0.0.1]:43367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w8GlI-0007rm-AR for submit <at> debbugs.gnu.org; Thu, 02 Apr 2026 08:03:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48668) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w8GlF-0007rN-IU for 80712 <at> debbugs.gnu.org; Thu, 02 Apr 2026 08:02:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w8GlA-0000n9-9J; Thu, 02 Apr 2026 08:02:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5Nzv4CwVh7c2g8R196UcB4QLGfG9oceDomvNAp3q180=; b=iGsYxfeP2hS4 Bd+mX0ADCkRBU0klL6TcLAaSTtJ8lJwxcj2/eiqk6CDQWRQLgScqNRRMYr+5PKqhpSvAVWHiXJ8aG +SLIO8z9dKheV3sHVlAq5aWIm/18Qe6LhJ0Ea7RVEH1OyeYivX2IWLfW3iz8BHH2YOCRYvO3HUqdt PpmUTgZF9WIQ32GJ8FEcvca2wFUE7+VFeQB+xMn3zhS7VlLtXaYEPHs9yqIMKjzeHAfMxAOKXYVKq XqI2NneKNYedMdoGveBg3HpkFO8MSPTYQlue9+dlntPg5+Sd2l4pqRdJ7u605AhLG/3gYSoRwZr7E /WPRc44+dOAC4EEZuMtYjA==; Date: Thu, 02 Apr 2026 15:02:40 +0300 Message-Id: <86a4vl8t9b.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87341e60mq.fsf@localhost> (message from Ihor Radchenko on Wed, 01 Apr 2026 17:39:29 +0000) Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> <87341e60mq.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, pipcet@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 80712 <at> debbugs.gnu.org > From: Ihor Radchenko <yantar92@HIDDEN> > Date: Wed, 01 Apr 2026 17:39:29 +0000 > > Pip Cet <pipcet@HIDDEN> writes: > > >>>>> cat /proc/sys/vm/max_map_count > >>>> 65530 > > > > So it is the max_map_count thing. Were you doing anything unusual at the > > time? > > Not really. Btw, what is the value of errno inside ProtSet? Is that ENOMEM or something else?
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 2 Apr 2026 12:01:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 02 08:01:18 2026 Received: from localhost ([127.0.0.1]:43345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w8Gjd-0007iE-El for submit <at> debbugs.gnu.org; Thu, 02 Apr 2026 08:01:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42960) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w8Gja-0007hZ-De for 80712 <at> debbugs.gnu.org; Thu, 02 Apr 2026 08:01:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1w8GjU-0000bm-6M; Thu, 02 Apr 2026 08:01:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Xxn9cLRhXSBWiZM0ufs9Qhb6v7NbdaQ9KAsmfCr9agU=; b=MtrIIHI385gx 32ZWmlu1tIOo8e4w82nsGAMu3TLW4DF5LSeUetaEeVgcb1gJ8rqAUviL/10hsHuul06LIdDXa7Rrn uOdm3/YaHuKRoTXQbrNQ38qNaK3i8Abjrfnl05UPGku8G2G/nIjSVsqLT8iYVdvkTAnqnhLLxNiJW Rtve5MX5k7luzcz4RDkUhiwouw7wp8LHAWVz1C9vfzPXsJWWWxsXUDenR20RVuCZA+S20KfM7vgqv fg0l/sO+/CFtOt7DpOryxJLpd5QoHULJdwvk/54iRWa26P62KQ6p7LSiIQHiivb0/1WPCY5fX2tgt kGOm8SX1XRDVjl9v4Y+i1w==; Date: Thu, 02 Apr 2026 14:59:49 +0300 Message-Id: <86bjg18te2.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87v7eay42o.fsf@HIDDEN> (message from Pip Cet on Wed, 01 Apr 2026 17:37:01 +0000) Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org, yantar92@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 80712 <at> debbugs.gnu.org > Date: Wed, 01 Apr 2026 17:37:01 +0000 > From: Pip Cet <pipcet@HIDDEN> > > "Ihor Radchenko" <yantar92@HIDDEN> writes: > > > Pip Cet <pipcet@HIDDEN> writes: > > > >> Can you run > >> > >> wc -l /proc/4810/maps > >> > >> as well? I don't know which of the maps show up in map_files and which > >> don't. > > > >> wc -l /proc/4810/maps > > 65531 /proc/4810/maps > > > >>>> Also, can you inspect /proc/sys/vm/max_map_count? > >>> > >>>> cat /proc/sys/vm/max_map_count > >>> 65530 > > So it is the max_map_count thing. Were you doing anything unusual at the > time? > > It might be necessary to increase the arena grain size to avoid running > into this over and over again, at least when max_map_count is at its > default setting. Can we detect this situation in advance and call memory_full when the count is close enough to 65530? That should prevent fatal signals and the real risk of losing the edits.
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 1 Apr 2026 17:39:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 01 13:39:40 2026 Received: from localhost ([127.0.0.1]:58590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w7zXX-0006l9-DA for submit <at> debbugs.gnu.org; Wed, 01 Apr 2026 13:39:40 -0400 Received: from mout01.posteo.de ([185.67.36.65]:46029) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1w7zXT-0006jQ-UD for 80712 <at> debbugs.gnu.org; Wed, 01 Apr 2026 13:39:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9560C240028 for <80712 <at> debbugs.gnu.org>; Wed, 1 Apr 2026 19:39:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1775065169; bh=GhlAW6z7cAzdUmoO16LiK1NAkUNDznxSxXGzrMdZEyM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=NuhV639Pv3un+kqLiLVLi7/Xv6HzXl/NYDgUBYLtXk+PyK9XF0fNjpWmVqc+Vbox9 OpwL9SIGFAF1WXXXvNyh6MDFGB+KMx3a6Gp390ywVGI1/PhloNrtgD7Ai0zzPznXUC jnDNzf+h0e4rcsSz0xU419/ECZx6ndenpoMhDzZx8Ph7C+tTPDM6d69c79r1MquLK4 jmgYH2sUATEIUcC0VDNAdNMGL51wl03EgXLC0GBPxdxPEKnmNZe1sLfCLMQPck1QJe HY+tt6ZsiqDW1AazIZpCwvOnibdx2SKmjHFnDJgFfvK5K6fQc8b+BEDewHcnK4mMY8 COflXgGrQObTg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fmC0d1PQDz6tvy; Wed, 1 Apr 2026 19:39:29 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <87v7eay42o.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> <87v7eay42o.fsf@HIDDEN> Date: Wed, 01 Apr 2026 17:39:29 +0000 Message-ID: <87341e60mq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.3 (-) Pip Cet <pipcet@HIDDEN> writes: >>>>> cat /proc/sys/vm/max_map_count >>>> 65530 > > So it is the max_map_count thing. Were you doing anything unusual at the > time? Not really. > It might be necessary to increase the arena grain size to avoid running > into this over and over again, at least when max_map_count is at its > default setting. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 1 Apr 2026 17:37:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 01 13:37:17 2026 Received: from localhost ([127.0.0.1]:58572 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w7zVF-0006Tf-33 for submit <at> debbugs.gnu.org; Wed, 01 Apr 2026 13:37:17 -0400 Received: from mail-244121.protonmail.ch ([109.224.244.121]:10079) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1w7zVB-0006SM-Hs for 80712 <at> debbugs.gnu.org; Wed, 01 Apr 2026 13:37:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1775065026; x=1775324226; bh=bCB/T7sdc71UMy8v45sw7qUBMM9g5fZU1asO4MR3jW8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=i20s5ys3uTe7CfLm7+aNoNxriNIGYb91HPpAyZOCtxWjj1gxBsLqGhItha7NQwpIV paY5ivHaxSkMXhIDvyRlEOEMF4a6h8UUalgjwRm+RPDMvFK1BudpgkUUbJOKgHu8rM rz0w64hovyEwhF3tC0EjX5Yh3bjSWeLl9y/u3mO6FgEhH7r86E0jrdySz6oDDauzL+ /X7c+LCe5DWnNzq/Sry6ySxTb7jncQ609q5qhDHnu5eIspMKASM7cqpueqhdYWd8Eo DkjJ28QlWBKHmI5AXqiGUMJaI5+6VCP5ygCKkZi2m3xOHcyeo1VZx6lS0wYt/smZX1 13DpzpTy4ciCg== Date: Wed, 01 Apr 2026 17:37:01 +0000 To: Ihor Radchenko <yantar92@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR Message-ID: <87v7eay42o.fsf@HIDDEN> In-Reply-To: <87cy0k7x2u.fsf@localhost> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> <87cy0k7x2u.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 53d85a227b94cfc6f9f729eeeb5ae63b7d387e0c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) "Ihor Radchenko" <yantar92@HIDDEN> writes: > Pip Cet <pipcet@HIDDEN> writes: > >> Can you run >> >> wc -l /proc/4810/maps >> >> as well? I don't know which of the maps show up in map_files and which >> don't. > >> wc -l /proc/4810/maps > 65531 /proc/4810/maps > >>>> Also, can you inspect /proc/sys/vm/max_map_count? >>> >>>> cat /proc/sys/vm/max_map_count >>> 65530 So it is the max_map_count thing. Were you doing anything unusual at the time? It might be necessary to increase the arena grain size to avoid running into this over and over again, at least when max_map_count is at its default setting. Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 31 Mar 2026 17:01:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 31 13:01:16 2026 Received: from localhost ([127.0.0.1]:40512 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w7cSn-0000ZZ-DS for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 13:01:15 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55825) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1w7cSh-0000XU-Tn for 80712 <at> debbugs.gnu.org; Tue, 31 Mar 2026 13:01:10 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5DA9E240028 for <80712 <at> debbugs.gnu.org>; Tue, 31 Mar 2026 19:01:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1774976461; bh=toDB3ncoH4tjy+bvfPq9ijMVVgdCKUmfUrezeQFZpTI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=X0RKDDhnOrkgX54ht1Ejkj/m9ijrXNzAGR1+dLjuUkoI73r8HEZcDCO3CphnubJuJ 6xTUyXFHbFMChTQpQnChh2n6SJW4ZNxGDF8u2aCYqY2lUw/HB2tnqvBqs3V0AsKvP0 GhMBV4jhG7Iid7RWSFejO7YPLtAKE4c//4djI0JPL7+nJ4krew8ahoS3Aq1HY78Vnt um6IBi68kNoyeuWcqbMBUDDUv2gkcAZXINMYP9TPT5RFbwNi/EH3ivp7XOAozpaeJq a+fhY54ooebg1w6X6gxZJIxA/e+dgF6IEu8AwtJOXQtxEii958YDCZwQyVFe8HdY44 rBRtnhEd1NWMw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4flZBh1D6Vz6txh; Tue, 31 Mar 2026 19:01:00 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <877bqsym22.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> <87fr5g7xrn.fsf@localhost> <877bqsym22.fsf@HIDDEN> Date: Tue, 31 Mar 2026 17:01:00 +0000 Message-ID: <87cy0k7x2u.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.3 (-) Pip Cet <pipcet@HIDDEN> writes: > Can you run > > wc -l /proc/4810/maps > > as well? I don't know which of the maps show up in map_files and which > don't. > wc -l /proc/4810/maps 65531 /proc/4810/maps >>> Also, can you inspect /proc/sys/vm/max_map_count? >> >>> cat /proc/sys/vm/max_map_count >> 65530 -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at 80712) by debbugs.gnu.org; 31 Mar 2026 16:56:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 31 12:56:42 2026
Received: from localhost ([127.0.0.1]:40421 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w7cOO-0008SL-6U
for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:56:42 -0400
Received: from mail-4322.protonmail.ch ([185.70.43.22]:47057)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1w7cOJ-0008Qy-HR
for 80712 <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:56:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1774976187; x=1775235387;
bh=21wcbyRw0IRuleaBQtMP0E+XbRdHDhgG5Q/Biv23GG0=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=y5IA+YQIswPxgn169sEaKg5mmSyijEy4P62s1lkWlSWkag83rXhtH5GJiTMRplloC
GxfnKdUS/ILVb0zu1BBiTP3q8MWsSc1wfR12ELt8X+7KnbmlVYQe8zgouL86r1m7Tu
rh+V5tbJ/OEgauIVMiIJLTqcG6bnc7nvXSEUinoFxVv1UYd1KPN6wV8wHQQCfqfntj
y2KZbiiJc92bY1vu/LqwQelzNsKIgo2cgX4KqeIxYX0zH/HkT/d0S0BoIGsYTbNtBL
ZnCVu6N1Xx7fH2KCw5m7AJE4wBBl1K2Ko6OzB9SPdJg4/XTQFUmqXI+DuPX4A9VUNw
RXkbOWZpFoAaQ==
Date: Tue, 31 Mar 2026 16:56:21 +0000
To: Ihor Radchenko <yantar92@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR
Message-ID: <877bqsym22.fsf@HIDDEN>
In-Reply-To: <87fr5g7xrn.fsf@localhost>
References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN>
<87fr5g7xrn.fsf@localhost>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: a2058d84ae3efd116ab8c312af798ec8ff4f5f4f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: "Ihor Radchenko" writes: > Pip Cet writes: >>>
../mps/code/protix.c:118:
Emacs fatal error: assertion failed: unreachable code >>> >>>
../mps/code/protix.c:118:
Emacs fatal error: assertion failed: unreachable code >> >> Is [...]
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.70.43.22 listed in sa-trusted.bondedsender.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [185.70.43.22 listed in list.dnswl.org]
1.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[185.70.43.22 listed in bl.score.senderscore.com]
-0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4)
[185.70.43.22 listed in wl.mailspike.net]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (pipcet[at]protonmail.com)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RCVD_IN_MSPIKE_WL Mailspike good senders
X-Debbugs-Envelope-To: 80712
Cc: 80712 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)
"Ihor Radchenko" <yantar92@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>>> ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreacha=
ble code
>>>
>>> ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreacha=
ble code
>>
>> Is this a large session?
>
> Typical, which means large.
I'm thinking bug#76705 ...
>> Can you figure out the Emacs pid, then inspect /proc/<pid>/maps to see
>> how many maps there are?
>
> $ ps aux | grep emacs
> yantar92 4800 0.2 1.5 1094340 492424 pts/0 Sl+ Mar30 3:28 gdb ./=
emacs
> yantar92 4810 1.9 15.5 6540700 5036416 pts/0 tl Mar30 28:47 /home/=
yantar92/Git/emacs/src/emacs
> yantar92 19467 0.0 0.2 91844 80272 ? Ss Mar30 0:05 /home/=
yantar92/.emacs.d/straight/build/pdf-tools/epdfinfo
> yantar92 297384 0.0 0.0 2920 1776 pts/4 Ss+ Mar30 0:00 /home/=
yantar92/.emacs.d/straight/repos/calctex/vendor/texd/dvichop calctex.dvi
> yantar92 707709 0.0 0.0 2892 1936 pts/5 S+ 07:30 0:00 emacsclient -F
> '(fullscreen . maximized) -c -e (require 'elfeed-org) -e (elfeed-org)
> -e (elfeed)
> yantar92 1468160 2.5 1.3 1022916 420044 pts/2 Sl 18:26 0:27 gdb ./=
emacs
> yantar92 1468176 7.6 4.9 2483816 1600424 pts/2 Sl+ 18:26 1:20 /home/=
yantar92/Git/emacs/src/emacs
> yantar92 1470395 0.0 0.0 7976 4200 ? Ss 18:28 0:00 /bin/b=
ash /home/yantar92/.local/bin/emacs-start.sh
> yantar92 1470396 0.0 0.0 2888 1812 ? S 18:28 0:00 emacsclient -c -n
> -e (switch-to-buffer (quote "*scratch*")) -e (boon-set-command-state)
> yantar92 1494934 0.0 0.0 13776 8716 pts/7 Ss+ 18:41 0:00 ssh -l
> yantar92 -o ControlMaster=3Dauto -o
> ControlPath=3D/home/yantar92/.cache/emacs/tramp.%C -o ControlPersist=3Dno
> -o SetEnv=3DTERM=3Ddumb -e none fp.gnu.org
> yantar92 1499526 0.0 0.0 6944 2572 pts/1 S+ 18:44 0:00 grep -=
-color=3Dauto emacs
>
> $ ll /proc/4810/map_files/ | wc -l
> 5453
Can you run
wc -l /proc/4810/maps
as well? I don't know which of the maps show up in map_files and which
don't.
>> Also, can you inspect /proc/sys/vm/max_map_count?
>
>> cat /proc/sys/vm/max_map_count
> 65530
An easy way to avoid these crashes (if it is bug#76705) is to
drastically increase that number (some problems with core dumps may
happen, but I don't even know whether that is from the pre-ELF days).
We might be able to work around it in MPS now we have our own copy to
work with...
Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 31 Mar 2026 16:46:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 31 12:46:20 2026 Received: from localhost ([127.0.0.1]:40278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w7cEN-00078b-MD for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:46:20 -0400 Received: from mout01.posteo.de ([185.67.36.65]:50207) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1w7cEJ-00077r-EJ for 80712 <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:46:17 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BA18B240027 for <80712 <at> debbugs.gnu.org>; Tue, 31 Mar 2026 18:46:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1774975568; bh=PUISIgWJ9yt5QS86NUJEISLP0TpLN9caDu04QxYX9EU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=QcKNzptX+CPlNgKc30mtrqLkBCimwddA3NWbkdjeVTMFrJjTrQs3i0poP1k7ReZgA qDNWnDUkY/RAAMOOWBixSnHr5KzwV4mJxkJlYtRG9Q1IXEAyGXkGdRH1FTaAv2Ukxr +OmfAAYfy+u0zKZKPLs5w2Ob2urAiRo8zRrnHnZts0rhCln3dYv9/8oatf3y2CYqWN 4kFQxi0E4HWHP0pwgvvzjF7jMPdUAeDRYNf0j8QcAC9/QVbMv3buMrsoqFqlTgruqW 6/eLigA2l02tKhYY/2Au7AmKKECA7FP5WDRSruIL6b+1YMO/vNTVU02o0m1p9UwUOm YbIF08VJ0YJdg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4flYsW66BGz9rxM; Tue, 31 Mar 2026 18:46:07 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR In-Reply-To: <87cy0kymtz.fsf@HIDDEN> References: <87ikac7yho.fsf@localhost> <87cy0kymtz.fsf@HIDDEN> Date: Tue, 31 Mar 2026 16:46:08 +0000 Message-ID: <87fr5g7xrn.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.3 (-) Pip Cet <pipcet@HIDDEN> writes: >> ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachable code >> >> ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachable code > > Is this a large session? Typical, which means large. > Can you figure out the Emacs pid, then inspect /proc/<pid>/maps to see > how many maps there are? $ ps aux | grep emacs yantar92 4800 0.2 1.5 1094340 492424 pts/0 Sl+ Mar30 3:28 gdb ./emacs yantar92 4810 1.9 15.5 6540700 5036416 pts/0 tl Mar30 28:47 /home/yantar92/Git/emacs/src/emacs yantar92 19467 0.0 0.2 91844 80272 ? Ss Mar30 0:05 /home/yantar92/.emacs.d/straight/build/pdf-tools/epdfinfo yantar92 297384 0.0 0.0 2920 1776 pts/4 Ss+ Mar30 0:00 /home/yantar92/.emacs.d/straight/repos/calctex/vendor/texd/dvichop calctex.dvi yantar92 707709 0.0 0.0 2892 1936 pts/5 S+ 07:30 0:00 emacsclient -F '(fullscreen . maximized) -c -e (require 'elfeed-org) -e (elfeed-org) -e (elfeed) yantar92 1468160 2.5 1.3 1022916 420044 pts/2 Sl 18:26 0:27 gdb ./emacs yantar92 1468176 7.6 4.9 2483816 1600424 pts/2 Sl+ 18:26 1:20 /home/yantar92/Git/emacs/src/emacs yantar92 1470395 0.0 0.0 7976 4200 ? Ss 18:28 0:00 /bin/bash /home/yantar92/.local/bin/emacs-start.sh yantar92 1470396 0.0 0.0 2888 1812 ? S 18:28 0:00 emacsclient -c -n -e (switch-to-buffer (quote "*scratch*")) -e (boon-set-command-state) yantar92 1494934 0.0 0.0 13776 8716 pts/7 Ss+ 18:41 0:00 ssh -l yantar92 -o ControlMaster=auto -o ControlPath=/home/yantar92/.cache/emacs/tramp.%C -o ControlPersist=no -o SetEnv=TERM=dumb -e none fp.gnu.org yantar92 1499526 0.0 0.0 6944 2572 pts/1 S+ 18:44 0:00 grep --color=auto emacs $ ll /proc/4810/map_files/ | wc -l 5453 > Also, can you inspect /proc/sys/vm/max_map_count? > cat /proc/sys/vm/max_map_count 65530 -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.Received: (at 80712) by debbugs.gnu.org; 31 Mar 2026 16:39:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 31 12:39:54 2026 Received: from localhost ([127.0.0.1]:40179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w7c8A-0006D5-Eb for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:39:54 -0400 Received: from mail-10630.protonmail.ch ([79.135.106.30]:62873) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1w7c86-0006Bs-UH for 80712 <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:39:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1774975184; x=1775234384; bh=0y7h0Ku96MP2YT51MtSYSk/IOL50zd7H/xFvic4wJlA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Of9lqd1TrojFXTsXji9xlX1aN+ofrbGs+YineC2D6+WxAKTX3/L9wFSKpwLtHelAS KW+wjNgkYOn04IoTyv/E5fq8uVZtJBDxzuVluR8nrOrbL4+LNmH+B17SKApqEDKlYN pcAK3EaKmwI1g3h+Bn+grkKLpKEOlPSZQk8j9Izf/bWwuK0VPbqYzHBf2Nm1KfAlRW fz0kdtf1I4zNJmy3PlcnuM189uolROLx4ZHYQq9baniB0p8HZhy1MvcCWLnFDGv23M FMVb0nz2bIzBU/9GkzfXvOkBOQ465cuP8F9SkMZj/hsz6c3juq7izZXdzLq96tZGaH hZzi/nQxvyyqA== Date: Tue, 31 Mar 2026 16:39:39 +0000 To: Ihor Radchenko <yantar92@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#80712: 31.0.50; MPS cash PVEC_SUBR Message-ID: <87cy0kymtz.fsf@HIDDEN> In-Reply-To: <87ikac7yho.fsf@localhost> References: <87ikac7yho.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cbfa7d0014ea002af95839a6f475bc2a4e780347 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 80712 Cc: 80712 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.7 (/) "Ihor Radchenko" <yantar92@HIDDEN> writes: > Hi, > > Just got another crash. > I will try to keep gdb alive. > > ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachabl= e code > > ../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachabl= e code Is this a large session? Can you figure out the Emacs pid, then inspect /proc/<pid>/maps to see how many maps there are? Also, can you inspect /proc/sys/vm/max_map_count? Thanks! Pip
bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 31 Mar 2026 16:31:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 31 12:31:10 2026
Received: from localhost ([127.0.0.1]:40056 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w7bzX-00054B-OP
for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:31:10 -0400
Received: from lists.gnu.org ([2001:470:142::17]:58930)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yantar92@HIDDEN>)
id 1w7bzR-00052d-Qf
for submit <at> debbugs.gnu.org; Tue, 31 Mar 2026 12:30:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yantar92@HIDDEN>)
id 1w7bzL-0002GC-Jg
for bug-gnu-emacs@HIDDEN; Tue, 31 Mar 2026 12:30:48 -0400
Received: from mout02.posteo.de ([185.67.36.66])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yantar92@HIDDEN>)
id 1w7bzH-0006Di-1Z
for bug-gnu-emacs@HIDDEN; Tue, 31 Mar 2026 12:30:46 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 10231240103
for <bug-gnu-emacs@HIDDEN>; Tue, 31 Mar 2026 18:30:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017;
t=1774974632; bh=QuKNINgB0BjixE/duTWWJX/cmrV9bZDi56B0Irr1GOg=;
h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From;
b=TOfmxMcnBGe84VkM+WN+vNIEyKkO3XuYSgLUfCD55b2OpDn7DBE6iRwF8Tk6Lqn4W
dKr38bHM539N3HkfvO2ylSSct18p5JwthrOgJjbTz7xltZQEXwCPJTgg2wR3tuPLC5
fQfBXne4k2l+VY3bSzuq8cfiKeTF00lQqAdXa6d8E+Vu9TQ1CvnQfdeEISsPnxFeo7
hx/QiTptwBK1v95sARrK2bME1RHdUt9oEDP9IwAo9m6bydQkG3sghfP8IG/5JWyyHl
O7sHdAzxIOE3NZUe+Y2AFXUJfPZbUoh+Gb5yljtwhuWCaANn36zXGIvse6kSOY1jo/
/t2fSdoYlJwkQ==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4flYWW0SX1z6txT
for <bug-gnu-emacs@HIDDEN>; Tue, 31 Mar 2026 18:30:30 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; MPS cash PVEC_SUBR
X-Debbugs-Cc:
Date: Tue, 31 Mar 2026 16:30:31 +0000
Message-ID: <87ikac7yho.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@HIDDEN;
helo=mout02.posteo.de
X-Spam_score_int: -23
X-Spam_score: -2.4
X-Spam_bar: --
X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.01,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=1, RCVD_IN_VALIDITY_RPBL_BLOCKED=1,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
Hi,
Just got another crash.
I will try to keep gdb alive.
../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachable code
../mps/code/protix.c:118: Emacs fatal error: assertion failed: unreachable code
Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:444
444 {
(gdb) bt
#0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:444
#1 0x00005555557e17a8 in set_state (state=IGC_STATE_DEAD) at igc.c:1118
#2 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at igc.c:310
#3 0x0000555555815b70 in mps_lib_assert_fail
(file=file@entry=0x5555558be328 "../mps/code/protix.c", line=line@entry=118, condition=condition@entry=0x5555558b8ac5 "unreachable code")
at ../mps/code/mpsliban.c:87
#4 0x000055555586f304 in ProtSet (base=0x7fffe0400000, limit=<optimized out>, mode=mode@entry=0) at ../mps/code/protix.c:118
#5 0x000055555586f4dd in arenaExpose (arena=0x7ffff7fb5000) at ../mps/code/traceanc.c:588
#6 ArenaPostmortem (globals=globals@entry=0x7ffff7fb5008) at ../mps/code/traceanc.c:617
#7 0x000055555586f55f in mps_arena_postmortem (arena=0x7ffff7fb5000) at ../mps/code/mpsi.c:296
#8 0x00005555557df40f in igc_postmortem () at igc.c:5922
#9 0x00005555557e1799 in set_state (state=IGC_STATE_DEAD) at igc.c:1117
#10 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at igc.c:310
#11 0x0000555555815b70 in mps_lib_assert_fail
(file=file@entry=0x5555558be328 "../mps/code/protix.c", line=line@entry=118, condition=condition@entry=0x5555558b8ac5 "unreachable code")
at ../mps/code/mpsliban.c:87
#12 0x000055555586f304 in ProtSet (base=0x7fff0d99c000, limit=<optimized out>, mode=0) at ../mps/code/protix.c:118
#13 0x000055555586fb3c in shieldProtLower (shield=shield@entry=0x7ffff7fb5658, seg=seg@entry=0x7fff8fe9d198, mode=mode@entry=3) at ../mps/code/shield.c:305
#14 0x000055555586ff29 in ShieldExpose (arena=arena@entry=0x7ffff7fb5000, seg=seg@entry=0x7fff8fe9d198) at ../mps/code/shield.c:737
#15 0x0000555555870d1a in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, arena=arena@entry=0x7ffff7fb5000, seg=seg@entry=0x7fff8fe9d198)
at ../mps/code/trace.c:1282
#16 0x0000555555870e8f in traceScanSeg (ts=ts@entry=1, rank=1, arena=arena@entry=0x7ffff7fb5000, seg=seg@entry=0x7fff8fe9d198) at ../mps/code/trace.c:1359
#17 0x0000555555870fe5 in TraceSegAccess (arena=arena@entry=0x7ffff7fb5000, seg=seg@entry=0x7fff8fe9d198, mode=mode@entry=1) at ../mps/code/trace.c:1412
#18 0x000055555587d2f8 in SegWholeAccess (seg=0x7fff8fe9d198, arena=0x7ffff7fb5000, addr=0x7fff0d99cd80, mode=1, context=0x7fffffff8e10)
at ../mps/code/seg.c:1271
#19 0x000055555587cd9d in SegAccess
(seg=0x7fff8fe9d198, arena=arena@entry=0x7ffff7fb5000, addr=addr@entry=0x7fff0d99cd80, mode=1, context=context@entry=0x7fffffff8e10)
at ../mps/code/seg.c:726
#20 0x000055555587d038 in ArenaAccess (addr=0x7fff0d99cd80, mode=<optimized out>, mode@entry=3, context=context@entry=0x7fffffff8e10)
at ../mps/code/global.c:671
#21 0x000055555587d839 in sigHandle (sig=11, info=0x7fffffff9130, uap=0x7fffffff9000) at ../mps/code/protsgix.c:97
#22 0x00007ffff2844410 in <signal handler called> () at /usr/lib64/libc.so.6
#23 0x00007fffba0b381f in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-element-73f7e592-dc2f4f0d.eln
#24 0x00005555557596c6 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff9ed0) at eval.c:3296
#25 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff9ed0)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#26 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffff9ec8) at eval.c:3228
#27 0x00007fffba0e9460 in F6f72672d656c656d656e742d2d63616368652d66696e64_org_element__cache_find_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-element-73f7e592-dc2f4f0d.eln
#28 0x00005555557596d9 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffa0c0) at eval.c:3298
#29 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffa0c0)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#30 0x0000555555759a80 in Ffuncall (nargs=3, args=0x7fffffffa0b8) at eval.c:3228
--Type <RET> for more, q to quit, c to continue without paging--
#31 0x00007fffba105ff5 in F6f72672d656c656d656e742d2d70617273652d746f_org_element__parse_to_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-element-73f7e592-dc2f4f0d.eln
#32 0x00005555557596f0 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffa518) at eval.c:3300
#33 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffa518)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#34 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffffa510) at eval.c:3228
#35 0x00007fffba132827 in F6f72672d656c656d656e742d61742d706f696e74_org_element_at_point_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-element-73f7e592-dc2f4f0d.eln
#36 0x00005555557596d9 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffa698) at eval.c:3298
#37 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffa698)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#38 0x0000555555759a80 in Ffuncall (nargs=1, args=0x7fffffffa690) at eval.c:3228
#39 0x00007fffceadae0f in F6f72672d6261636b2d746f2d68656164696e67_org_back_to_heading_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-cd6b4d00-8d7a56bd.eln
#40 0x000055555575ae89 in eval_sub (form=<optimized out>) at eval.c:2718
#41 0x000055555575b459 in Fprogn (body=<optimized out>, body@entry=0x7fff64bff85b) at eval.c:460
#42 0x0000555555748ee9 in Fsave_excursion (args=0x7fff64bff85b) at editfns.c:839
#43 0x000055555575acb5 in eval_sub (form=<optimized out>) at eval.c:2669
#44 0x000055555575c5e9 in Flet (args=<optimized out>) at eval.c:1179
#45 0x000055555575acb5 in eval_sub (form=<optimized out>) at eval.c:2669
#46 0x000055555575b459 in Fprogn (body=<optimized out>) at eval.c:460
#47 0x000055555575b8a4 in funcall_lambda (fun=fun@entry=0x7fff6e5250ed, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffaad0) at eval.c:3485
#48 0x000055555575b9d7 in apply_lambda (fun=fun@entry=0x7fff6e5250ed, args=<optimized out>, count=count@entry=...) at eval.c:3350
#49 0x000055555575afc6 in eval_sub (form=<optimized out>) at eval.c:2765
#50 0x000055555575b459 in Fprogn (body=<optimized out>) at eval.c:460
#51 0x000055555575b8a4 in funcall_lambda (fun=fun@entry=0x7fff6ef656fd, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffad30) at eval.c:3485
#52 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffad30) at eval.c:3179
#53 0x0000555555759a80 in Ffuncall (nargs=1, args=0x7fffffffad28) at eval.c:3228
#54 0x00007fffb9503b32 in F6f72672d6167656e64612d736b69702d6576616c_org_agenda_skip_eval_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#55 0x00005555557596c6 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffaeb8) at eval.c:3296
#56 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffaeb8)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#57 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffffaeb0) at eval.c:3228
#58 0x00007fffb9503a53 in F6f72672d6167656e64612d736b6970_org_agenda_skip_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#59 0x00005555557596c6 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff150) at eval.c:3296
#60 0x00005555557a01c9 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=257, nargs=<optimized out>,
nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffb340) at /home/yantar92/Git/emacs/src/lisp.h:2298
#61 0x000055555575b5c9 in funcall_lambda (fun=fun@entry=0x7ffeaae94045, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffb340) at eval.c:3387
#62 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffb340) at eval.c:3179
#63 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffffb338) at eval.c:3228
#64 0x00007fffba122c52 in F6f72672d656c656d656e742d63616368652d6d6170_org_element_cache_map_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-element-73f7e592-dc2f4f0d.eln
--Type <RET> for more, q to quit, c to continue without paging--c
#65 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=7, args=args@entry=0x7fffffffb838) at eval.c:3319
#66 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=7, args=args@entry=0x7fffffffb838)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#67 0x0000555555759a80 in Ffuncall (nargs=8, args=0x7fffffffb830) at eval.c:3228
#68 0x00007fffb9526368 in F6f72672d6167656e64612d6765742d7363686564756c6564_org_agenda_get_scheduled_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#69 0x00005555557596d9 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff118) at eval.c:3298
#70 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff118)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#71 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffde9ff110) at eval.c:3228
#72 0x0000555555757e40 in Fapply (nargs=2, args=0x7fffde9ff110) at eval.c:2842
#73 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffde9ff110) at eval.c:3319
#74 0x00005555557a01c9 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=128, nargs=<optimized out>,
nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffbd98) at /home/yantar92/Git/emacs/src/lisp.h:2298
#75 0x000055555575b5c9 in funcall_lambda (fun=fun@entry=0x7ffee6f79695, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffbd98) at eval.c:3387
#76 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffbd98) at eval.c:3179
#77 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffffbd90) at eval.c:3228
#78 0x00007fffb9511b2b in F6f72672d6167656e64612d6765742d6461792d656e7472696573_org_agenda_get_day_entries_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#79 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=6, args=args@entry=0x7fffffffbf58) at eval.c:3319
#80 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=6, args=args@entry=0x7fffffffbf58)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#81 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=7, args=args@entry=0x7fffffffbf50) at eval.c:3228
#82 0x0000555555758024 in Fapply (nargs=<optimized out>, args=<optimized out>) at eval.c:2885
#83 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffde9ff0d0) at eval.c:3319
#84 0x00005555557a01c9 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=128, nargs=<optimized out>,
nargs@entry=6, args=<optimized out>, args@entry=0x7fffffffc228) at /home/yantar92/Git/emacs/src/lisp.h:2298
#85 0x000055555575b5c9 in funcall_lambda (fun=fun@entry=0x7ffeee795a5d, nargs=nargs@entry=6, arg_vector=arg_vector@entry=0x7fffffffc228) at eval.c:3387
#86 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=6, args=args@entry=0x7fffffffc228) at eval.c:3179
#87 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=7, args=args@entry=0x7fffffffc220) at eval.c:3228
#88 0x0000555555758024 in Fapply (nargs=<optimized out>, args=<optimized out>) at eval.c:2885
#89 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffffffc4b8) at eval.c:3319
#90 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=4, args=args@entry=0x7fffffffc4b8)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#91 0x0000555555759a80 in Ffuncall (nargs=5, args=0x7fffffffc4b0) at eval.c:3228
#92 0x00007fffb95064c6 in F6f72672d6167656e64612d6c697374_org_agenda_list_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#93 0x000055555575970b in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff078) at eval.c:3302
#94 0x00005555557a01c9 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=0, nargs=<optimized out>,
nargs@entry=0, args=<optimized out>, args@entry=0x7fffffffc758) at /home/yantar92/Git/emacs/src/lisp.h:2298
#95 0x000055555575b5c9 in funcall_lambda (fun=fun@entry=0x7ffeab708575, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffc758) at eval.c:3387
#96 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=0, args=args@entry=0x7fffffffc758) at eval.c:3179
#97 0x0000555555759a80 in Ffuncall (nargs=1, args=0x7fffffffc750) at eval.c:3228
#98 0x000055555575ade1 in eval_sub (form=<optimized out>) at eval.c:2690
#99 0x000055555575b459 in Fprogn (body=<optimized out>) at eval.c:460
#100 0x000055555575c78d in Flet (args=<optimized out>) at /home/yantar92/Git/emacs/src/lisp.h:1555
#101 0x000055555575acb5 in eval_sub (form=form@entry=0x7ffeab708723) at eval.c:2669
#102 0x000055555575cdd2 in Feval (form=0x7ffeab708723, lexical=<optimized out>) at eval.c:2566
#103 0x00005555557596d9 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffcb28) at eval.c:3298
#104 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffcb28)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#105 0x0000555555759a80 in Ffuncall (nargs=2, args=0x7fffffffcb20) at eval.c:3228
#106 0x00007fffb94f7a0f in F6f72672d6167656e6461_org_agenda_0 () at /home/yantar92/.emacs.d/eln-cache/31.0.50-f27bcba0/org-agenda-784bc5b0-d94ad9f3.eln
#107 0x00005555557596f0 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff048) at eval.c:3300
#108 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffde9ff048)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#109 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffde9ff040) at eval.c:3228
#110 0x0000555555757e40 in Fapply (nargs=2, args=0x7fffde9ff040) at eval.c:2842
#111 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffde9ff040) at eval.c:3319
#112 0x00005555557a01c9 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, args_template@entry=128, nargs=<optimized out>,
nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffd050) at /home/yantar92/Git/emacs/src/lisp.h:2298
#113 0x000055555575b5c9 in funcall_lambda (fun=fun@entry=0x7fff3dd3a905, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffd050) at eval.c:3387
#114 0x000055555575bbe5 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd050) at eval.c:3179
#115 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd048) at eval.c:3228
#116 0x0000555555753bb0 in Ffuncall_interactively (nargs=2, args=0x7fffffffd048) at callint.c:253
#117 0x00005555557597b4 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffd048) at eval.c:3319
#118 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffffd048)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#119 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fffffffd040) at eval.c:3228
#120 0x00005555557555e5 in Fcall_interactively (function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at callint.c:803
#121 0x00007fffdf8210e5 in F636f6d6d616e642d65786563757465_command_execute_0 ()
at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-f27bcba0/preloaded/simple-fab5b0cf-84df7285.eln
#122 0x000055555575970b in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd3f8) at eval.c:3302
#123 0x000055555575bba9 in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffffd3f8)
at /home/yantar92/Git/emacs/src/lisp.h:2298
#124 0x0000555555759a80 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd3f0) at eval.c:3228
#125 0x00005555556e51fd in command_loop_1 () at keyboard.c:1562
#126 0x00005555557566eb in internal_condition_case
(bfun=bfun@entry=0x5555556e4ade <command_loop_1>, handlers=handlers@entry=0xa8, hfun=hfun@entry=0x5555556d646a <cmd_error>) at eval.c:1712
#127 0x00005555556d1177 in command_loop_2 (handlers=handlers@entry=0xa8) at keyboard.c:1180
#128 0x0000555555756623 in internal_catch (tag=tag@entry=0x15cb0, func=func@entry=0x5555556d1147 <command_loop_2>, arg=arg@entry=0xa8) at eval.c:1392
#129 0x00005555556d1124 in command_loop () at keyboard.c:1158
#130 0x00005555556d5fe9 in recursive_edit_1 () at keyboard.c:766
#131 0x00005555556d6383 in Frecursive_edit () at keyboard.c:849
#132 0x00005555556d0291 in main (argc=<optimized out>, argv=0x7fffffffd8a8) at emacs.c:2657
Lisp Backtrace:
0x67ef4638 PVEC_SUBR
"org-element--cache-find" (0xffffa0c0)
"org-element--parse-to" (0xffffa518)
"org-element-at-point" (0xffffa698)
"org-back-to-heading" (0xffffa770)
"save-excursion" (0xffffa858)
"let" (0xffffa9a8)
"yant/org-agenda-skip-org-ql" (0xffffaad0)
"yant/org-agenda-skip-nofocus" (0xffffad30)
"org-agenda-skip-eval" (0xffffaeb8)
"org-agenda-skip" (0xde9ff150)
0xaae94040 PVEC_CLOSURE
"org-element-cache-map" (0xffffb838)
0xe6f7b6e0 PVEC_SUBR
"apply" (0xde9ff110)
"org-agenda-get-scheduled" (0xffffbd98)
0xee796bf0 PVEC_SUBR
"apply" (0xde9ff0d0)
"org-agenda-get-day-entries" (0xffffc228)
"apply" (0xffffc4b8)
"org-agenda-list" (0xde9ff078)
0xab708570 PVEC_CLOSURE
"funcall" (0xffffc750)
"let" (0xffffc8e8)
"eval" (0xffffcb28)
0x3dd3e910 PVEC_SUBR
"apply" (0xde9ff040)
"org-agenda" (0xffffd050)
"funcall-interactively" (0xffffd048)
"command-execute" (0xffffd3f8)
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.51, cairo version 1.18.4) of 2026-03-29 built on localhost
Repository revision: 62cfc1d29306f828c44545fc85749157433dca16
Repository branch: feature/igc3
Windowing system distributor 'The X.Org Foundation', version 11.0.12101021
System Description: Gentoo Linux
Configured using:
'configure --with-mps=yes --with-native-compilation CFLAGS=-g3
JAVAC=/etc/java-config-2/current-system-vm/bin/javac
PKG_CONFIG_PATH=/usr/share/guile-data/3.0/pkgconfig'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP
X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Ihor Radchenko <yantar92@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#80712; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.