Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 09:44:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 19 04:44:43 2025
Received: from localhost ([127.0.0.1]:44937 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tZRrG-00069R-E6
for submit <at> debbugs.gnu.org; Sun, 19 Jan 2025 04:44:43 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22]:18623)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1tZRrC-000697-IM
for 75632 <at> debbugs.gnu.org; Sun, 19 Jan 2025 04:44:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1737279871; x=1737539071;
bh=T8ma193+CFUkgRqTGxsrDPojv0ecgJS9kPOetz/BwLI=;
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:List-Unsubscribe:List-Unsubscribe-Post;
b=Wqf0Qi2eqA0oK3idH/enqYYU+pRXmz458rB/IvId0UHGdKuPS6cqay3s23u9o6WCb
Q2plHHNlVgvh3bRy+g00oq8uUwPZQ6pEE2j/OfFLVsxlbjCiW0CJX5i+EadOxYbHqa
9DlxHik/tWa9rozurQzaDYaWCzJXFIOMqN1UDvU+n6klKwdvL3g/8bd9hO/B3FbKqs
2tqNFocCH/+o1OCwfxKRn2wTxEF4rlFeD3ykjRO8Sw3oTdUPHqnfmZXKFfPhXkN3Qy
1Vcn+4uJwfCksnhvJowyAYwXuUn4FDKsWZeMmUkPyr+wVeMRWcxEAh8NQWJsi/7M4B
xttYLZLydVfVA==
Date: Sun, 19 Jan 2025 09:44:26 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75632: 31.0.50; igc: Crash report
Message-ID: <87ldv72l5l.fsf@HIDDEN>
In-Reply-To: <86v7ub8iqx.fsf@HIDDEN>
References: <87a5bpo6bv.fsf@localhost> <875xmcci55.fsf@HIDDEN>
<86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN>
<864j1w9chu.fsf@HIDDEN> <877c6rc30l.fsf@HIDDEN>
<861pwzanav.fsf@HIDDEN> <87sepfam9u.fsf@HIDDEN>
<86v7ub8iqx.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 860fbea919266a7173232aa97ef8595c1a0e5165
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.8 (-)
X-Debbugs-Envelope-To: 75632
Cc: yantar92@HIDDEN, 75632 <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: -2.8 (--)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Sat, 18 Jan 2025 20:40:47 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> > But if we use !initialized, the code which installs the variable
>> > watcher will not run in the dumped Emacs, right?
>>
>> Correct. Variable watchers are symbol properties, and symbol properties
>> are restored from the dump, so there is no need to add them again.
>
> Then why do we need to do this in C and not in Lisp? Can't we set up
> the watcher as part of some preloaded Lisp file?
>
>> >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag
>> >> >> directly (or use QUITP); we wouldn't be able to break out of one o=
f
>> >> >> those if we only set Vinhibit_quit from what's currently
>> >> >> store_user_signal_events, would we?
>> >> >
>> >> > Sorry, I don't follow. Why does it matter whether we set those
>> >> > variables from a signal handler or in gobble_input?
>> >>
>> >> We might never reach gobble_input if the variable isn't set in the
>> >> signal handler: some loops check QUITP (etc.), and if there's a bug i=
n
>> >> them and Vinhibit_quit is set, the loop might never call maybe_quit.
>> >
>> > Then how about setting Vquit_flag and resetting Vinhibit_quit in the
>> > handler, but leaving the check whether we should call the debugger to
>> > gobble_input?
>>
>> 1. We can't do that unconditionally. An ordinary SIGUSR2 should not
>> cause a quit, only a special event should. So we need to check whether
>> the event we received is special or not.
>>
>> 2. probably_quit handles the quit flag first, then handles pending
>> signals only when it is called again, by the next maybe_quit. That
>> means by the time we reach gobble_input, it's too late to call the
>> debugger. So we need to set debug_* at the same time as setting
>> Vquit_flag (or rewrite probably_quit, which probably has very good
>> reasons for its peculiar behavior).
>
> OK, but could we at least make this somewhat cleaner? Instead of
I see no reason for why the old code behaved as it did, so I'm proposing
this:
1. doc change: don't use "special event" to mean two totally different
things in process_special_events and special_event_name; remove
special_event_name.
2. when debug-on-event is modified/called, set a per-signal flag in the
user_signal_info struct, saving us a strcmp.
3. Add a watcher as on feature/igc to reset the flags of all user
signals.
4. Make that watcher callable as Fdebug_on_event directly.
I stopped there. I'm confused about input_available_clear_time: it's
only cleared if we don't enter the debugger. Adding the code to clear
it to the debug_on_event case might help us break out of some broken
pselects, and it shouldn't ever hurt us (famous last words).
But maybe I totally misunderstood what you suggested, too.
diff --git a/src/keyboard.c b/src/keyboard.c
index fa19c9f8ad3..217ec6582fc 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -8254,6 +8254,10 @@ deliver_input_available_signal (int sig)
/* Signal number. */
int sig;
=20
+ /* True if this event is supposed to make us enter the debugger
+ instead of its normal behavior. */
+ bool debug_on_event;
+
/* Name of the signal. */
char *name;
=20
@@ -8279,6 +8283,7 @@ add_user_signal (int sig, const char *name)
=20
p =3D xmalloc (sizeof *p);
p->sig =3D sig;
+ p->debug_on_event =3D false;
p->name =3D xstrdup (name);
p->npending =3D 0;
p->next =3D user_signals;
@@ -8288,42 +8293,68 @@ add_user_signal (int sig, const char *name)
sigaction (sig, &action, 0);
}
=20
+DEFUN ("debug_on_event", Fdebug_on_event, Sdebug_on_event, 1, 4, 0,
+ doc: /* Make EVENT enter the debugger.
+
+EVENT should be a symbol, either sigusr1 or sigusr2.
+
+This function supports an additional calling convention to be usable as
+a variable watcher. */)
+ (Lisp_Object arg_or_symbol, Lisp_Object newval, Lisp_Object operation,
+ Lisp_Object where)
+{
+ Lisp_Object ret =3D Qnil;
+ Lisp_Object symbol =3D arg_or_symbol;
+ if (EQ (symbol, Qdebug_on_event))
+ symbol =3D newval;
+
+ CHECK_SYMBOL (symbol);
+
+ struct user_signal_info *p;
+ for (p =3D user_signals; p; p =3D p->next)
+ if (SYMBOLP (symbol) && strcmp (SSDATA (SYMBOL_NAME (symbol)), p->name=
) =3D=3D 0)
+ {
+=09p->debug_on_event =3D true;
+=09ret =3D Qt;
+ }
+ else
+ p->debug_on_event =3D false;
+
+ Vdebug_on_event =3D symbol;
+
+ return ret;
+}
+
static void
handle_user_signal (int sig)
{
struct user_signal_info *p;
- const char *special_event_name =3D NULL;
-
- if (SYMBOLP (Vdebug_on_event))
- special_event_name =3D SSDATA (SYMBOL_NAME (Vdebug_on_event));
=20
for (p =3D user_signals; p; p =3D p->next)
if (p->sig =3D=3D sig)
{
- if (special_event_name
-=09 && strcmp (special_event_name, p->name) =3D=3D 0)
+=09if (p->debug_on_event)
{
/* Enter the debugger in many ways. */
debug_on_next_call =3D true;
debug_on_quit =3D true;
Vquit_flag =3D Qt;
Vinhibit_quit =3D Qnil;
-
- /* Eat the event. */
- break;
}
-
-=09p->npending++;
-#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL)
-=09if (interrupt_input)
-=09 handle_input_available_signal (sig);
=09else
-#endif
=09 {
-=09 /* Tell wait_reading_process_output that it needs to wake
-=09 up and look around. */
-=09 if (input_available_clear_time)
-=09 *input_available_clear_time =3D make_timespec (0, 0);
+=09 p->npending++;
+#if defined (USABLE_SIGIO) || defined (USABLE_SIGPOLL)
+=09 if (interrupt_input)
+=09 handle_input_available_signal (sig);
+=09 else
+#endif
+=09 {
+=09=09/* Tell wait_reading_process_output that it needs to wake
+=09=09 up and look around. */
+=09=09if (input_available_clear_time)
+=09=09 *input_available_clear_time =3D make_timespec (0, 0);
+=09 }
=09 }
=09break;
}
@@ -12755,6 +12786,16 @@ init_keyboard (void)
poll_suppress_count =3D 1;
start_polling ();
#endif
+
+ DEFSYM (Qdebug_on_event, "debug-on-event");
+
+ /* Variable watchers persist across the dump, no need to add them
+ twice. */
+ if (!initialized)
+ {
+ Fadd_variable_watcher (Qdebug_on_event, Qdebug_on_event);
+ }
+ Fdebug_on_event (Qdebug_on_event, Vdebug_on_event, Qnil, Qnil);
}
=20
/* This type's only use is in syms_of_keyboard, to put properties on the
@@ -13139,6 +13180,7 @@ syms_of_keyboard (void)
defsubr (&Sevent_symbol_parse_modifiers);
defsubr (&Sevent_convert_list);
defsubr (&Sinternal_handle_focus_in);
+ defsubr (&Sdebug_on_event);
defsubr (&Sread_key_sequence);
defsubr (&Sread_key_sequence_vector);
defsubr (&Srecursive_edit);
> copying the name of the event aside, can we produce a C integer that
> identifies the event, and store that number instead? Accessing
Sorry, I ignored this when writing the patch. I don't think we should
hardcode any assumptions about signal numbers, and I don't see another
readily available integer we can use; in any case, it's now trivial to
modify debug-on-event so several events enter the debugger. This might
be handy for the Android port, which, IIUC, currently binds
triple-volume-down to quit, not to enter the debugger. (I think all
other ports have stable signal handling interfaces, but I may be wrong).
> integers from a signal handler should not be a problem, right? (In
> retrospect, we should have probably made debug-on-event a function,
> then we could produce that number inside the function, thus avoiding
> the need for watching the variable. Maybe we should introduce the
> function now and deprecate the variable?)
I've introduced a function, so you can call debug-on-event or set it,
but I haven't deprecated the variable yet, because there's no way to
read the value from Lisp otherwise.
With this change, we still have six (!) debug-on-* variables, and two
additional debug-on-* functions. They all behave slightly differently.
Is this at all what you meant? I realize it's incomplete, but it's
probably worth it to do things properly.
Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 19 Jan 2025 05:39:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 19 00:39:48 2025 Received: from localhost ([127.0.0.1]:44527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZO2F-00087d-Tr for submit <at> debbugs.gnu.org; Sun, 19 Jan 2025 00:39:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37608) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZO2C-00087E-Ih for 75632 <at> debbugs.gnu.org; Sun, 19 Jan 2025 00:39:45 -0500 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 1tZO26-0001u5-J9; Sun, 19 Jan 2025 00:39:38 -0500 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=uC7l6rQN40yDl6OYsVLb77m8bqP1bol41TrrBYXnink=; b=Mv7+sPO40mgW 12VyU5W/q/v1hWZNpqPSaVF0GF29Yz2ozDs1CP1eylGnZURkjIY9nFOYVOQvR/8Il7PEHmKbM32dI yWlCh9Qx/gGCXmq48RK0+ipwIDMLTU5qW0U0CHl/ZGhysCOOfvZiDVhfOXZCOI2D5cctRj9Aa5Dc2 wDAt6teS0a95N+V+XGWnMcWRV+J3c8QONWc0jmBEGkzYVAkygHc5T46Q3w6LVmIHlaKjZe2gKgu6M WSsajvSLUcg+9JlCP8U4562fDM9wvLilwqS1BDxr0W5m4ESfbSSnTQb2XACvDT4yiixXzekP+mQp+ 3jtExR6xq1Xgqo5L3RSAEw==; Date: Sun, 19 Jan 2025 07:39:34 +0200 Message-Id: <86v7ub8iqx.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87sepfam9u.fsf@HIDDEN> (message from Pip Cet on Sat, 18 Jan 2025 20:40:47 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> <86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN> <864j1w9chu.fsf@HIDDEN> <877c6rc30l.fsf@HIDDEN> <861pwzanav.fsf@HIDDEN> <87sepfam9u.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Sat, 18 Jan 2025 20:40:47 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > But if we use !initialized, the code which installs the variable > > watcher will not run in the dumped Emacs, right? > > Correct. Variable watchers are symbol properties, and symbol properties > are restored from the dump, so there is no need to add them again. Then why do we need to do this in C and not in Lisp? Can't we set up the watcher as part of some preloaded Lisp file? > >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > >> >> directly (or use QUITP); we wouldn't be able to break out of one of > >> >> those if we only set Vinhibit_quit from what's currently > >> >> store_user_signal_events, would we? > >> > > >> > Sorry, I don't follow. Why does it matter whether we set those > >> > variables from a signal handler or in gobble_input? > >> > >> We might never reach gobble_input if the variable isn't set in the > >> signal handler: some loops check QUITP (etc.), and if there's a bug in > >> them and Vinhibit_quit is set, the loop might never call maybe_quit. > > > > Then how about setting Vquit_flag and resetting Vinhibit_quit in the > > handler, but leaving the check whether we should call the debugger to > > gobble_input? > > 1. We can't do that unconditionally. An ordinary SIGUSR2 should not > cause a quit, only a special event should. So we need to check whether > the event we received is special or not. > > 2. probably_quit handles the quit flag first, then handles pending > signals only when it is called again, by the next maybe_quit. That > means by the time we reach gobble_input, it's too late to call the > debugger. So we need to set debug_* at the same time as setting > Vquit_flag (or rewrite probably_quit, which probably has very good > reasons for its peculiar behavior). OK, but could we at least make this somewhat cleaner? Instead of copying the name of the event aside, can we produce a C integer that identifies the event, and store that number instead? Accessing integers from a signal handler should not be a problem, right? (In retrospect, we should have probably made debug-on-event a function, then we could produce that number inside the function, thus avoiding the need for watching the variable. Maybe we should introduce the function now and deprecate the variable?)
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 20:41:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 15:41:02 2025 Received: from localhost ([127.0.0.1]:43911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZFcs-0003Q2-8c for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 15:41:02 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:27017) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tZFcp-0003PJ-5o for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 15:41:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737232851; x=1737492051; bh=9YVcSwmnlrZ5u/u6NBaIwxGctT3wr0sWOuulOJ6SgjM=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=AjSY8SJZM9O0GXizlOlUS53SlL/buBHRz5DOmAkR/PVroeJaOhOrhoU5uWdKT9swZ U6i6a0QZavlEPyEK7zqM700ifyBI3sGw0h31tU81rViPNCQDnim/PxGln/l3WCtDtC GmcFqaVjXgFNm4EEQNVlmgFYrPu2QMu5NkbltXgesgdm5MsXB4hPq21SHHfLjRer8Q okqdyi4nVKe9R1ZvBsObomGw6WtAl5nYd+/uBbL0aoJwzUtlCOUPOUGOSeEDeOOyOu pW2Pim8BTH1Zs/vM96tJUas5S0/sRfeDmzdyCHhNeq2Pm+dn0oVHFqt9H3FlgCIJGD 1GvDkN2Ny7LWA== Date: Sat, 18 Jan 2025 20:40:47 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87sepfam9u.fsf@HIDDEN> In-Reply-To: <861pwzanav.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> <86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN> <864j1w9chu.fsf@HIDDEN> <877c6rc30l.fsf@HIDDEN> <861pwzanav.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 43b9df2d3c394230deb3a27904916a13a6af04a9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Sat, 18 Jan 2025 19:53:50 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> So (!initialized) it is? That works for temacs and emacs (I original= ly >> >> thought it would be wasteful for non-interactive temacs, but I'm sure >> >> someone's using that :-) ). >> > >> > As long as we understand well what it means to free in emacs a string >> > that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed >> > in emacs to something else, how would xfree work in that case? >> >> pdumper doesn't work that way (unexec did, I think): a static variable >> that isn't "remembered" by pdumper isn't saved, and it starts out as >> NULL in the dumped Emacs, and is replaced by the new xstrdup. The old >> xstrdup (and the memory it allocated) are gone after the dump. > > But if we use !initialized, the code which installs the variable > watcher will not run in the dumped Emacs, right? Correct. Variable watchers are symbol properties, and symbol properties are restored from the dump, so there is no need to add them again. >> >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag >> >> directly (or use QUITP); we wouldn't be able to break out of one of >> >> those if we only set Vinhibit_quit from what's currently >> >> store_user_signal_events, would we? >> > >> > Sorry, I don't follow. Why does it matter whether we set those >> > variables from a signal handler or in gobble_input? >> >> We might never reach gobble_input if the variable isn't set in the >> signal handler: some loops check QUITP (etc.), and if there's a bug in >> them and Vinhibit_quit is set, the loop might never call maybe_quit. > > Then how about setting Vquit_flag and resetting Vinhibit_quit in the > handler, but leaving the check whether we should call the debugger to > gobble_input? 1. We can't do that unconditionally. An ordinary SIGUSR2 should not cause a quit, only a special event should. So we need to check whether the event we received is special or not. 2. probably_quit handles the quit flag first, then handles pending signals only when it is called again, by the next maybe_quit. That means by the time we reach gobble_input, it's too late to call the debugger. So we need to set debug_* at the same time as setting Vquit_flag (or rewrite probably_quit, which probably has very good reasons for its peculiar behavior). Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 20:18:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 15:18:32 2025 Received: from localhost ([127.0.0.1]:43881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZFH6-0002MG-15 for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 15:18:32 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47780) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZFH3-0002M0-CT for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 15:18:30 -0500 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 1tZFGw-0001zV-88; Sat, 18 Jan 2025 15:18:22 -0500 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=2ttK+dV0qqmXOKc0ICd00gwidmumw51bZrw3wChcaRI=; b=JFMhiO9m1mUZ ztiRFxZt8qp/zFnsJWXD7SSENzj0dUOqQsi4wPmhb8BYHCpsmcDVEPjDgzRSdwST8C7GJDMVvri+t SvLlqfkujY/cemmnt/ktG9C/i8aUXZszmyaswvI6RzipcHstPA0m41FCkEdBRgKrkcWmCf1zCyL+q SlDdg+aZLelqT/4GWi2DtlnH17VGe/o75UzvnHl8uUDATE0D9AsmFDt8XHu4EM0WFwAzCu4KAEMi3 EC/bNf6ckJXQD6mIsJhmdwJmB2fXoO/H44b5+cv5vOwYmPO3I4rBLw2kUYAcd+66SP4lq3XwphZna T7Xo0/h28DP3SDDpSTNwxQ==; Date: Sat, 18 Jan 2025 22:18:16 +0200 Message-Id: <861pwzanav.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <877c6rc30l.fsf@HIDDEN> (message from Pip Cet on Sat, 18 Jan 2025 19:53:50 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> <86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN> <864j1w9chu.fsf@HIDDEN> <877c6rc30l.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Sat, 18 Jan 2025 19:53:50 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> So (!initialized) it is? That works for temacs and emacs (I originally > >> thought it would be wasteful for non-interactive temacs, but I'm sure > >> someone's using that :-) ). > > > > As long as we understand well what it means to free in emacs a string > > that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed > > in emacs to something else, how would xfree work in that case? > > pdumper doesn't work that way (unexec did, I think): a static variable > that isn't "remembered" by pdumper isn't saved, and it starts out as > NULL in the dumped Emacs, and is replaced by the new xstrdup. The old > xstrdup (and the memory it allocated) are gone after the dump. But if we use !initialized, the code which installs the variable watcher will not run in the dumped Emacs, right? > >> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > >> directly (or use QUITP); we wouldn't be able to break out of one of > >> those if we only set Vinhibit_quit from what's currently > >> store_user_signal_events, would we? > > > > Sorry, I don't follow. Why does it matter whether we set those > > variables from a signal handler or in gobble_input? > > We might never reach gobble_input if the variable isn't set in the > signal handler: some loops check QUITP (etc.), and if there's a bug in > them and Vinhibit_quit is set, the loop might never call maybe_quit. Then how about setting Vquit_flag and resetting Vinhibit_quit in the handler, but leaving the check whether we should call the debugger to gobble_input?
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.
Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 19:54:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 14:54:08 2025
Received: from localhost ([127.0.0.1]:43840 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tZEtT-00018y-OO
for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 14:54:08 -0500
Received: from mail-4316.protonmail.ch ([185.70.43.16]:35217)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1tZEtQ-00018Q-9A
for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 14:54:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1737230037; x=1737489237;
bh=f6p1cJb6n6Oqhn0+ZAkq9eJ5UNEjAulIHzAjgSZdy/M=;
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:List-Unsubscribe:List-Unsubscribe-Post;
b=H+XOlL/Ja7VuJBSu6Jg7jgE0nt163udQ0s+A9GT218njtMoKI1YFBmXf7LmySUIWh
YkHVjq+t6KE+4z9GYft7Ue1fyYxXEcpHUagHBJeyMQp6E6t9flSEPxiX2zFZSAMbhs
1fuPCM2PgIVCZWBcyuRG+3XwBeBAhm3wVBeElzbm8p2pvt7GxGxQfc71jgUix+OBEv
CgiGg5WTZ0Uod78RJTlOT1WOxmktR9KieDDqqmnXCn4IPRrJxqdUTStPpaXvJgnB5r
XNiRUwjJkGDfVFJIMKz7fszNsbCeW4Jza71K424WbwPM7vzQ9y27jQZgf1pq6wRgiB
oVC6bY6tja8ZA==
Date: Sat, 18 Jan 2025 19:53:50 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75632: 31.0.50; igc: Crash report
Message-ID: <877c6rc30l.fsf@HIDDEN>
In-Reply-To: <864j1w9chu.fsf@HIDDEN>
References: <87a5bpo6bv.fsf@localhost> <87a5bpf7ri.fsf@HIDDEN>
<86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN>
<86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN>
<86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN>
<864j1w9chu.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 1f7aa3032192ca088555104732c6604c11f55f2e
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75632
Cc: yantar92@HIDDEN, 75632 <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.0 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Sat, 18 Jan 2025 17:31:57 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> >> I think it's important to keep temacs/emacs without dumping runnable.
>> >> It's certainly still interesting when temacs is called emacs.
>> >
>> > Yes, of course, no argument here.
>>
>> So (!initialized) it is? That works for temacs and emacs (I originally
>> thought it would be wasteful for non-interactive temacs, but I'm sure
>> someone's using that :-) ).
>
> As long as we understand well what it means to free in emacs a string
> that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed
> in emacs to something else, how would xfree work in that case?
pdumper doesn't work that way (unexec did, I think): a static variable
that isn't "remembered" by pdumper isn't saved, and it starts out as
NULL in the dumped Emacs, and is replaced by the new xstrdup. The old
xstrdup (and the memory it allocated) are gone after the dump.
>> > I'd be much happier if we instead treated this as we treat SIGIO that
>> > is delivered when the user presses a keyboard key: set a flag saying
>> > that input is available, and then process it as we do with keyboard.
>>
>> IIRC, there are some loops that test Vinhibit_quit or Vquit_flag
>> directly (or use QUITP); we wouldn't be able to break out of one of
>> those if we only set Vinhibit_quit from what's currently
>> store_user_signal_events, would we?
>
> Sorry, I don't follow. Why does it matter whether we set those
> variables from a signal handler or in gobble_input?
We might never reach gobble_input if the variable isn't set in the
signal handler: some loops check QUITP (etc.), and if there's a bug in
them and Vinhibit_quit is set, the loop might never call maybe_quit.
For example, SIGUSR2 should be able to interrupt this loop in gap_right:
while (1)
{
/* I gets number of characters left to copy. */
i =3D bytepos - new_s1;
if (i =3D=3D 0)
=09break;
/* If a quit is requested, stop copying now.
=09 Change BYTEPOS to be where we have actually moved the gap to.
=09 Note that this cannot happen when we are called to make the
=09 gap larger or smaller, since make_gap_larger and
=09 make_gap_smaller set inhibit-quit. */
if (QUITP)
=09{
/* FIXME: This can point in the middle of a multibyte character. =
*/
=09 bytepos =3D new_s1;
=09 charpos =3D BYTE_TO_CHAR (bytepos);
=09 break;
=09}
/* Move at most 32000 chars before checking again for a quit. */
if (i > 32000)
=09i =3D 32000;
new_s1 +=3D i;
memmove (to, from, i);
from +=3D i, to +=3D i;
}
Since QUITP is defined as
#define QUITP (!NILP (Vquit_flag) && NILP (Vinhibit_quit))
that means the signal handler (not gobble_input) needs to touch these
flags.
It's possible to add something like
if (pending_signals)
{
ptrdiff_t old_bytepos =3D bytepos;
ptrdiff_t old_charpos =3D charpos;
bytepos =3D new_s1;
charpos =3D BYTE_TO_CHAR (bytepos);
maybe_quit ();
}
to this loop, and then it would be interruptible by SIGUSR2, but it
would also be interruptible by other input events, so I'm not sure that
wouldn't cause crashes.
>> > The SIGUSR event is eventually entered into the keyboard buffer
>> > anyway, so why should we treat it so differently from SIGIO?
>>
>> Vdebug_on_event isn't, AFAICS. Not a major change to make it so,
>> though. I don't know why we eat this event, but we do.
>
> I guess because we want the debugger to pop up before any queued
> events are processed.
"instead of", I think. That's a detail I don't care much for: I think
it'd be helpful for sigusr2 to show up in M-x view-lossage even if it
triggered the debugger.
> But I don't see why doing the same in
> gobble_input should produce different behavior.
while (true)
{
while (!QUITP);
maybe_quit();
)
should be interruptible by SIGUSR2.
Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 18:57:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 13:57:30 2025 Received: from localhost ([127.0.0.1]:43768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZE0g-00072J-3O for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 13:57:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50548) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZE0d-000720-KW for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 13:57:28 -0500 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 1tZE0Q-0008D8-TR; Sat, 18 Jan 2025 13:57:21 -0500 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=pkpEMV5zYxztlhg5r2U8QWMV5mLWxF5dN2PSARvPwU4=; b=a5eVpaYbG8qQ JO17XB6vk6PP4lKJV+nVqcCg9r+K8fjgl71RDVVr9AfOWHQ7zH5AR1teKuPFuokOxtPvKb3Kp1bhs ZbfIzvzutR0De/hH+dqilnQ1RltObnz8QiCwCkztW7ZQHfwiSqcNYxZk53rtMLsVWMsp92slOwIkH ZyjeLJ54kg2t1M87CfAbNamd67Vf+/tgFmyr/BcKYvSrc3nStiqUGT1tgKCJkEy3w/91DR134aLNE GiT24sFWDVjYIjYHkX4HIc9goHl2tPCvG9VLGmgz3SDBj/GIB0Pv/tCSZsVuaaS3Ddua9bJJTLzSh tbZTL1DzS7Hg5i8Wuf6hPg==; Date: Sat, 18 Jan 2025 20:57:01 +0200 Message-Id: <864j1w9chu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87jzasav0j.fsf@HIDDEN> (message from Pip Cet on Sat, 18 Jan 2025 17:31:57 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> <86a5bo9l53.fsf@HIDDEN> <87jzasav0j.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Sat, 18 Jan 2025 17:31:57 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> I think it's important to keep temacs/emacs without dumping runnable. > >> It's certainly still interesting when temacs is called emacs. > > > > Yes, of course, no argument here. > > So (!initialized) it is? That works for temacs and emacs (I originally > thought it would be wasteful for non-interactive temacs, but I'm sure > someone's using that :-) ). As long as we understand well what it means to free in emacs a string that was xstrdup'ed in temacs, yes. Suppose debug-on-event is changed in emacs to something else, how would xfree work in that case? > > I'd be much happier if we instead treated this as we treat SIGIO that > > is delivered when the user presses a keyboard key: set a flag saying > > that input is available, and then process it as we do with keyboard. > > IIRC, there are some loops that test Vinhibit_quit or Vquit_flag > directly (or use QUITP); we wouldn't be able to break out of one of > those if we only set Vinhibit_quit from what's currently > store_user_signal_events, would we? Sorry, I don't follow. Why does it matter whether we set those variables from a signal handler or in gobble_input? > > The SIGUSR event is eventually entered into the keyboard buffer > > anyway, so why should we treat it so differently from SIGIO? > > Vdebug_on_event isn't, AFAICS. Not a major change to make it so, > though. I don't know why we eat this event, but we do. I guess because we want the debugger to pop up before any queued events are processed. But I don't see why doing the same in gobble_input should produce different behavior.
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 17:32:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 12:32:13 2025 Received: from localhost ([127.0.0.1]:43614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZCg8-0003Bu-LY for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 12:32:13 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:15277) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tZCg5-0003Bd-2c for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 12:32:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737221522; x=1737480722; bh=xh9mlulINOqerMmPgvqmGRDPLuXEoX06zDn58vr2jnA=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=XRkwdvysVgnCi3FKUHArAmbzAzHmd5U4plDunw2Ydludyd9hDoYM7xzotRyxEDl9c aG4OVLkuOkLZHjvQYmkY268FuXVkGg9RNj67lAkzAem6zjw2FoVKQqdAsQAIcZIwwG XKnXJqZCTIzk7nALWprThAD0HCom8J3M0IvvrK9xOZ9yHIoXNIsTw7xABjcW6hRsd0 DEnlefnZwQ6xXXLF5+rUnw2ZYocBb6YrkIrB0m1qyubXgdgSym4BqP+vrWV2yt/H2h CGtP3kXgLlsV8ELIO2SkvIPOg5q66xaZuLsK8rNLQJE+Gt39YtJXSn1SMu/2JoQTDO 0HtFT065QcVtQ== Date: Sat, 18 Jan 2025 17:31:57 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87jzasav0j.fsf@HIDDEN> In-Reply-To: <86a5bo9l53.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> <86a5bo9l53.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ec64371081db99378271554fe4cb83c0581dcaec MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Sat, 18 Jan 2025 14:27:03 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> I was talking about --with-dumping=3Dnone, not unexec builds. I"m no= t >> >> fixing unexec bugs! >> > >> > OK, so the only interesting use case is running temacs when not >> > dumping it. >> >> I think it's important to keep temacs/emacs without dumping runnable. >> It's certainly still interesting when temacs is called emacs. > > Yes, of course, no argument here. So (!initialized) it is? That works for temacs and emacs (I originally thought it would be wasteful for non-interactive temacs, but I'm sure someone's using that :-) ). >> >> Vdebug_on_event points to data behind a memory barrier. It's replace= d >> >> by a C string which is xstrdup'd, so that's not behind a memory barri= er. >> >> keeping the two in sync is done with a variable watcher, as is the ca= se >> >> for gc-cons-threshold. >> >> >> >> Variable watchers survive dump/reload cycles, so we set it up just on= ce, >> >> when !initialized; when entering the code in the post-dump state, we >> >> perform the initial dummy "watch" event to initialize the C string. >> > >> > OK, but what does this have to do with SIGUSR handling? >> >> The SIGUSR* handler needs to access that string. Signal handlers cannot >> access MPS-managed memory, so we need to put the string in regular >> xmalloc memory. > > So this is just to allow the signal handler access to the event name? So it can determine whether to set some flags, or mark an input signal pending and set some other flags, yes. > I'd be much happier if we instead treated this as we treat SIGIO that > is delivered when the user presses a keyboard key: set a flag saying > that input is available, and then process it as we do with keyboard. IIRC, there are some loops that test Vinhibit_quit or Vquit_flag directly (or use QUITP); we wouldn't be able to break out of one of those if we only set Vinhibit_quit from what's currently store_user_signal_events, would we? If we want to change behavior in this way, we should do it on master, then merge it into feature/igc. > The SIGUSR event is eventually entered into the keyboard buffer > anyway, so why should we treat it so differently from SIGIO? Vdebug_on_event isn't, AFAICS. Not a major change to make it so, though. I don't know why we eat this event, but we do. >> I think that's clear from the commit message, by the way. If it isn't, >> I'd appreciate advice on how to improve it. > > These details are better said in comments to the code than in commit > log messages. Looking for explanations for what the code does in Git > history is less convenient, and I'm quite sure some people will not > even think about it, at least not at first. Good point, agreed. Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 15:50:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 10:50:27 2025 Received: from localhost ([127.0.0.1]:43445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZB5e-0006vn-UJ for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 10:50:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60124) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZB5c-0006va-VL for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 10:50:25 -0500 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 1tZB5X-0001Kn-HM; Sat, 18 Jan 2025 10:50:19 -0500 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=grzAV87Tpn0yV+EnLEe0a2ondY4NTBIDwAaRnJ208EA=; b=GNcW3C4wJ4ZI WlO9yUKCxtgO7vpq4+5/i0NVfsltaYd1eYjDob4pTl/VF8OYwIiPoLUrVWw5cIoz35FDJmWjesRQy vftvf5F3YEKnIIAdceoJdyLq5sYAewK1DnXwVNLqnB1hVLSZ1F8wTQ4oyrNf/PzapIF/g+Z+xbPP6 I/9ABAD18KKfXMPwPaa0IJKoOqIx6+ekqJKjWWziyc4o8Ef5pHU7hDu48KMKrRZVx1q/9kGMGm2Fn rY6gPT1weAeDvcBrHo6hbeAJqtROedWpoutqAf4shCyofT3ZLNhmVPezR/cx8mMn4T/UJn47oFRpM jWvLPy/u4UrTGlqa7ylz9g==; Date: Sat, 18 Jan 2025 17:50:16 +0200 Message-Id: <86a5bo9l53.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <875xmcci55.fsf@HIDDEN> (message from Pip Cet on Sat, 18 Jan 2025 14:27:03 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> <875xmcci55.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Sat, 18 Jan 2025 14:27:03 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> I was talking about --with-dumping=none, not unexec builds. I"m not > >> fixing unexec bugs! > > > > OK, so the only interesting use case is running temacs when not > > dumping it. > > I think it's important to keep temacs/emacs without dumping runnable. > It's certainly still interesting when temacs is called emacs. Yes, of course, no argument here. > >> Vdebug_on_event points to data behind a memory barrier. It's replaced > >> by a C string which is xstrdup'd, so that's not behind a memory barrier. > >> keeping the two in sync is done with a variable watcher, as is the case > >> for gc-cons-threshold. > >> > >> Variable watchers survive dump/reload cycles, so we set it up just once, > >> when !initialized; when entering the code in the post-dump state, we > >> perform the initial dummy "watch" event to initialize the C string. > > > > OK, but what does this have to do with SIGUSR handling? > > The SIGUSR* handler needs to access that string. Signal handlers cannot > access MPS-managed memory, so we need to put the string in regular > xmalloc memory. So this is just to allow the signal handler access to the event name? I'd be much happier if we instead treated this as we treat SIGIO that is delivered when the user presses a keyboard key: set a flag saying that input is available, and then process it as we do with keyboard. The SIGUSR event is eventually entered into the keyboard buffer anyway, so why should we treat it so differently from SIGIO? > I think that's clear from the commit message, by the way. If it isn't, > I'd appreciate advice on how to improve it. These details are better said in comments to the code than in commit log messages. Looking for explanations for what the code does in Git history is less convenient, and I'm quite sure some people will not even think about it, at least not at first.
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 14:27:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 09:27:20 2025 Received: from localhost ([127.0.0.1]:40804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZ9nD-0002Zm-6Y for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 09:27:19 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:39649) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tZ9n9-0002ZV-8W for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 09:27:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737210428; x=1737469628; bh=YOUxyS6XCaZqk/+0BiklUp90SgY9VvxKKojV6AhfQNo=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=ohMrsDz6cgnW3Ecx9T0v6HieST1uHTlcYAl2tA9ZmkLE6GLnLPnxKmdHPsVCKXgVI VccfsAdEh58GHVQdaFPC+OS7P7F09XnG+4ftDlJlrV9FjX3YwGaUT8arL/nTbhA7Qi Qlf7nMRuOGs+6FllJwnS4mNP+LJQtEN28yx6VGDuYO2YqD14p3GGhgS1wPAlYE1tch 12v48ymHwKO8Eggif/2BlR4G9f56IfZuz3uzJRTQK2l40PpmsM23zQ2DhzSv6/q6DC RS9caYTrizPqt6gZiWWVC1SL+pYgsE/TeuCn/QOLggBdzFt8lqu4Tdh+Y5xgpowWtV xLcd4xEPTCJUQ== Date: Sat, 18 Jan 2025 14:27:03 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <875xmcci55.fsf@HIDDEN> In-Reply-To: <86o7049un4.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> <86o7049un4.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 59c468604785e2cb428d44c837e5128138fc4da7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Sat, 18 Jan 2025 11:42:44 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN >> >> >> But if we build without pdumper (after removing the relevant #error a= nd >> >> a few minor fixes, it works just fine), initialized is false, so SIGU= SR2 >> >> wouldn't work at all in those builds. >> > >> > Do we want to support MPS in unexec builds? I thought we didn't. >> > (Does it even work in such builds?) >> >> I was talking about --with-dumping=3Dnone, not unexec builds. I"m not >> fixing unexec bugs! > > OK, so the only interesting use case is running temacs when not > dumping it. I think it's important to keep temacs/emacs without dumping runnable. It's certainly still interesting when temacs is called emacs. >> >> In the pdumper case, it'd run in temacs, put the right subr in the >> >> symbol's plist, dump it, and then it'd be restored from the dump and >> >> we'd only need the initial call. >> >> >> >> Would that be okay? >> > >> > I have no idea, because I don't understand why is that the solution to >> > SIGUSR handling. (How about adding some comments which explain the >> > purpose of watching that variable?) Also see above regarding unexec >> > build with MPS. >> >> Vdebug_on_event points to data behind a memory barrier. It's replaced >> by a C string which is xstrdup'd, so that's not behind a memory barrier. >> keeping the two in sync is done with a variable watcher, as is the case >> for gc-cons-threshold. >> >> Variable watchers survive dump/reload cycles, so we set it up just once, >> when !initialized; when entering the code in the post-dump state, we >> perform the initial dummy "watch" event to initialize the C string. > > OK, but what does this have to do with SIGUSR handling? The SIGUSR* handler needs to access that string. Signal handlers cannot access MPS-managed memory, so we need to put the string in regular xmalloc memory. I think that's clear from the commit message, by the way. If it isn't, I'd appreciate advice on how to improve it. (Maybe it's a good idea to use the extended ChangeLog format with an explanatory paragraph between the header line (which some git utilities insist on keeping shorter than it should be) and the individual files' changes.) Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 12:25:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 07:25:17 2025 Received: from localhost ([127.0.0.1]:40645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZ7t6-0002NJ-Vy for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 07:25:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40800) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZ7t4-0002MV-Mk for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 07:25:15 -0500 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 1tZ7sy-0001VX-3W; Sat, 18 Jan 2025 07:25:08 -0500 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=L0PcXoiNfLx9xMg6bwqowaoGEsTJ2reUlmWo5mRTZvI=; b=MWlwTrK9WKX4 dmGGFmBDICWeIayotoem+QvVFjTs1XEr/LkQYVecIn/3KQ95JQHqv501DeouEKE0Hoz2UNiLWLHss ky9M4F3JYG6f9yrGrVFsZwq8PcjpQUXbtZnBQ+68GpkTMNJylms2ocvDeO6KprA9pxl2cjqADlyOa bcjcYAPmbwQVlChvaUbPpYSdGHNZSDP2MNitXcLk7+Uy8a+ukJobUKq3mwQBY8I25eJvA1MmRcpMn 4UuOv8kufPSVTz7n4whludtlPFyuBSaayFErmnCiU8Ux9vUjZxwBUDk7RGyBNIjMmvqE2tdpRZflu XTYKj0iR7Jo67egxGl4p/A==; Date: Sat, 18 Jan 2025 14:25:03 +0200 Message-Id: <86o7049un4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <874j1we4bh.fsf@HIDDEN> (message from Pip Cet on Sat, 18 Jan 2025 11:42:44 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> <874j1we4bh.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Sat, 18 Jan 2025 11:42:44 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > >> But if we build without pdumper (after removing the relevant #error and > >> a few minor fixes, it works just fine), initialized is false, so SIGUSR2 > >> wouldn't work at all in those builds. > > > > Do we want to support MPS in unexec builds? I thought we didn't. > > (Does it even work in such builds?) > > I was talking about --with-dumping=none, not unexec builds. I"m not > fixing unexec bugs! OK, so the only interesting use case is running temacs when not dumping it. > >> In the pdumper case, it'd run in temacs, put the right subr in the > >> symbol's plist, dump it, and then it'd be restored from the dump and > >> we'd only need the initial call. > >> > >> Would that be okay? > > > > I have no idea, because I don't understand why is that the solution to > > SIGUSR handling. (How about adding some comments which explain the > > purpose of watching that variable?) Also see above regarding unexec > > build with MPS. > > Vdebug_on_event points to data behind a memory barrier. It's replaced > by a C string which is xstrdup'd, so that's not behind a memory barrier. > keeping the two in sync is done with a variable watcher, as is the case > for gc-cons-threshold. > > Variable watchers survive dump/reload cycles, so we set it up just once, > when !initialized; when entering the code in the post-dump state, we > perform the initial dummy "watch" event to initialize the C string. OK, but what does this have to do with SIGUSR handling?
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 11:42:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 06:42:58 2025 Received: from localhost ([127.0.0.1]:40546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZ7EA-0005mk-Dg for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 06:42:58 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:31895) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tZ7E7-0005mV-Ba for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 06:42:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737200568; x=1737459768; bh=JeIxygCK43RrEKnuduRWubItG90znGOTO+ZZRacxRR0=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=ZQZPsatG2lh07GsBImjF1hdanwdNzzBo5+h7Yn44scH1DpzqszKfgQG5LRU78mpKH n1dgd52Q7gzzljDANXxBR0cA0KCSXdAAk8AifWzTekRP06NnKu08jKRuQL48SszF3g GzLXpIKgiH6c7TANd+Ak7rvi2oXpElgnglryaFjhvjmkxAQio52BRuNh+iIIiSHVMx mP0VB8durND/yEMeFicrm/ONJhTgBRUB3um71ygD///XnZvco6Q7Ff+7M8ndxs7Fyx 6sfkvPfOe0YlIyMiJeVAw0NSWsiPoKE9PKFuTj+cKsCAWzp47d21O1V0PgZqjReCnC 8/3z/vLLBTjag== Date: Sat, 18 Jan 2025 11:42:44 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <874j1we4bh.fsf@HIDDEN> In-Reply-To: <86msfod1hk.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> <86msfod1hk.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c4dee80d9c72b4be16863e924de56ae22573fe61 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 17 Jan 2025 21:30:41 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> I'm not sure what you are suggesting here. Is there a good place tha= t >> >> is initialized only in the !pdumper || !temacs case? >> > >> > The "if (initialized)" test is exactly for that. pdumper_load sets >> > initialized =3D true before it returns. So in temacs initialized will >> > be false when init_keyboard is called. >> >> But if we build without pdumper (after removing the relevant #error and >> a few minor fixes, it works just fine), initialized is false, so SIGUSR2 >> wouldn't work at all in those builds. > > Do we want to support MPS in unexec builds? I thought we didn't. > (Does it even work in such builds?) I was talking about --with-dumping=3Dnone, not unexec builds. I"m not fixing unexec bugs! >> In the pdumper case, it'd run in temacs, put the right subr in the >> symbol's plist, dump it, and then it'd be restored from the dump and >> we'd only need the initial call. >> >> Would that be okay? > > I have no idea, because I don't understand why is that the solution to > SIGUSR handling. (How about adding some comments which explain the > purpose of watching that variable?) Also see above regarding unexec > build with MPS. Vdebug_on_event points to data behind a memory barrier. It's replaced by a C string which is xstrdup'd, so that's not behind a memory barrier. keeping the two in sync is done with a variable watcher, as is the case for gc-cons-threshold. Variable watchers survive dump/reload cycles, so we set it up just once, when !initialized; when entering the code in the post-dump state, we perform the initial dummy "watch" event to initialize the C string. Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 18 Jan 2025 07:29:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 18 02:29:13 2025 Received: from localhost ([127.0.0.1]:39776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tZ3Gb-00047C-C1 for submit <at> debbugs.gnu.org; Sat, 18 Jan 2025 02:29:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43974) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tZ3GX-00046x-9L for 75632 <at> debbugs.gnu.org; Sat, 18 Jan 2025 02:29:11 -0500 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 1tZ3GR-0003Rn-5t; Sat, 18 Jan 2025 02:29:03 -0500 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=gnURSOCsPxQb/srOOXPXo1AACPmGC1IH6tRyLc3pERU=; b=ont7xnZzoOPo LhgX0MQR9K3LdrnGxYOPsI4KaXG1gDjgKYv07LF5cXupgr3HUZ2No+qtnZRAgFGOmh+v0lPQP54sH cgwevxKKJDjj6AbWz7RKiv7QMiMjC0HusrYXOQuMsFHXhdvzqbHRBEt6x8Z1z3O9CFkMwjYtd16yr L8t+b69urabZHeVKFOsrVDCvbU4zr2BdB08EllvyS0+DLdtkySBQ7MaeGuEgOlQd2ReD1NUJI8inY gK++kyLEQDeJhWREb1i5HV7QIJPHN6m+DNy0KIysXXMySGgWbOCucJJp0O5FRchhOEv9KtWkV57AS deRgCDsPOsziKewYs9djGA==; Date: Sat, 18 Jan 2025 09:28:55 +0200 Message-Id: <86msfod1hk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87a5bpf7ri.fsf@HIDDEN> (message from Pip Cet on Fri, 17 Jan 2025 21:30:41 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> <87a5bpf7ri.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Fri, 17 Jan 2025 21:30:41 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> I'm not sure what you are suggesting here. Is there a good place that > >> is initialized only in the !pdumper || !temacs case? > > > > The "if (initialized)" test is exactly for that. pdumper_load sets > > initialized = true before it returns. So in temacs initialized will > > be false when init_keyboard is called. > > But if we build without pdumper (after removing the relevant #error and > a few minor fixes, it works just fine), initialized is false, so SIGUSR2 > wouldn't work at all in those builds. Do we want to support MPS in unexec builds? I thought we didn't. (Does it even work in such builds?) > In the pdumper case, it'd run in temacs, put the right subr in the > symbol's plist, dump it, and then it'd be restored from the dump and > we'd only need the initial call. > > Would that be okay? I have no idea, because I don't understand why is that the solution to SIGUSR handling. (How about adding some comments which explain the purpose of watching that variable?) Also see above regarding unexec build with MPS.
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 21:30:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 16:30:56 2025 Received: from localhost ([127.0.0.1]:39063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tYtvc-0000AB-Bq for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:30:56 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:52017) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tYtvY-00009t-4h for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:30:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737149445; x=1737408645; bh=21HX3JWE59tpTeSS/ScGbBv2Zy2VbfkRfiqkC6kAVr4=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=pvRkjVNMmo1krLUZTLM4PiDNULNIDpG18Ac2hxdG+DuDiPkl7fpAyZoGmJKEyAQzF M5cECwMX5quhHtTeHBXivfSxaj7d9vWQrxVB9ErPvN4M89B11xPcINgck4+/ZzfDQD bgRFV2aASKTAbQ/3s1X69dtOf6ADZOJPfhMrP1SBH7Nfa1z8GPnWqUkctDJC5mv8qj NeWhoRAgJQcGFdslJrET9PKmlGeJqIln4aEJ9srNmz8valPADMcIiBVJxSS15B3rPD 0p1r5hi/Mz/9i/B9/Ye9UGjJWgY7/wnvLJWDxHfNErYdLNU+vdXKgTT9BpQHqdQrBQ BNU+4wJ2EM4Yg== Date: Fri, 17 Jan 2025 21:30:41 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87a5bpf7ri.fsf@HIDDEN> In-Reply-To: <86plklcft2.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> <86plklcft2.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c332aa81aae940d92c4bbb96984eadf0c882a6fc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 17 Jan 2025 20:52:58 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> > This breaks the MS-Windows build: temacs crashes as below: >> >> Sorry. Can you try the fix I just pushed? While I arrived at that >> independently (I was about to push when I got your email), I believe it >> explains your crash as well. > > It fixes the crash, thanks. Thanks! I still think we should initialize the vector header of subrs and the thread structure to contain the appropriate size fields. Subrs currently claim size 0 (and no auto-marked Lisp fields), which is confusing. Threads report totally incorrect values, because of what seems like a bug to me: VECSIZE is used where VECSIZE - PSEUDOVECSIZE is intended. But this problem was caused by the GC header, not the vectorlike header. Initializing the GC header is harder because of the hash value. (No great harm in leaving it set to 0 for those very few objects, though). >> > The following patch seems to fix that, but I'm not sure it's the >> > correct fix. Can you explain why we need to add-variable-watcher for >> > this in init_keyboard, in particular in temacs? >> >> I'm not sure what you are suggesting here. Is there a good place that >> is initialized only in the !pdumper || !temacs case? > > The "if (initialized)" test is exactly for that. pdumper_load sets > initialized =3D true before it returns. So in temacs initialized will > be false when init_keyboard is called. But if we build without pdumper (after removing the relevant #error and a few minor fixes, it works just fine), initialized is false, so SIGUSR2 wouldn't work at all in those builds. >> I don't think so, but it might call Fadd_variable_watcher twice. We >> should avoid that. > > So maybe the patch I proposed should be installed regardless. I had a look: Fadd_variable_watcher handles the case of several identical watchers by ignoring the second call. If we want to avoid calling Fadd_variable_watcher twice, we can use "if (!initialized)", which will run the code just once (however, the explicit call to watch_debug_on_event needs to be performed twice, before and after the dump, because the xstrdup()ed string isn't dumped). In the pdumper case, it'd run in temacs, put the right subr in the symbol's plist, dump it, and then it'd be restored from the dump and we'd only need the initial call. Would that be okay? Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 21:05:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 16:05:35 2025 Received: from localhost ([127.0.0.1]:39025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tYtX5-0007K1-Fv for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:05:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48592) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYtX2-0007Jm-BQ for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 16:05:34 -0500 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 1tYtWv-0006Nk-R0; Fri, 17 Jan 2025 16:05:25 -0500 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=rAS+q6cHMhBqUNUNlCPGbDZh7aumKcOMXvjXuKQWvR4=; b=eTwwqspp6dcM v0JzO0on0kykLzeqRVzn1TH3hlKigAcixPPCsqRahPn7dmaFNhbfRN8sKJGktrkcnupml9oU4TEO3 PlntSDtEbHyzR77ohHYfzs/owgjKWjaKjXuy+bz18QmKWY35ngVOTLXkWmwwoVwDUp/zFMO3nQrva oGFGo7+1TN4jZRwF45M3Sf/Q+I2nX+Tdm/qlkS5HM0HO3nXnbuL0EhVJQWs0T7tz2VHlwFknRaznM /BI41VXST4oAxoX1zhLUsI+jIgdcoWhXXl/Au3JR1RWteVyPruydl02Ja8MSS+XrT1jcurMrOYpd2 g+GESTlNNft0FpcJegj2lg==; Date: Fri, 17 Jan 2025 23:04:57 +0200 Message-Id: <86plklcft2.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87o705f9id.fsf@HIDDEN> (message from Pip Cet on Fri, 17 Jan 2025 20:52:58 +0000) Subject: Re: bug#75632: 31.0.50; igc: Crash report References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN> <86y0z9chcb.fsf@HIDDEN> <87o705f9id.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---) > Date: Fri, 17 Jan 2025 20:52:58 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 75632 <at> debbugs.gnu.org, yantar92@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > This breaks the MS-Windows build: temacs crashes as below: > > Sorry. Can you try the fix I just pushed? While I arrived at that > independently (I was about to push when I got your email), I believe it > explains your crash as well. It fixes the crash, thanks. > > The following patch seems to fix that, but I'm not sure it's the > > correct fix. Can you explain why we need to add-variable-watcher for > > this in init_keyboard, in particular in temacs? > > I'm not sure what you are suggesting here. Is there a good place that > is initialized only in the !pdumper || !temacs case? The "if (initialized)" test is exactly for that. pdumper_load sets initialized = true before it returns. So in temacs initialized will be false when init_keyboard is called. > I don't think so, but it might call Fadd_variable_watcher twice. We > should avoid that. So maybe the patch I proposed should be installed regardless.
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.
Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 20:53:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 15:53:12 2025
Received: from localhost ([127.0.0.1]:39011 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tYtL6-0006Z4-5i
for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 15:53:12 -0500
Received: from mail-10629.protonmail.ch ([79.135.106.29]:61567)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1tYtL4-0006Yh-1b
for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 15:53:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1737147183; x=1737406383;
bh=54qIZHfjKE9jg4L97UB59d3L5y9lVuaXen4yvrongB4=;
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:List-Unsubscribe:List-Unsubscribe-Post;
b=djf/H87Yt9zaxfsDzuUNGJGv7yfgFaZuQuf3Vx59jqeToa1Yd0qEnrMBh5MbJ9C+S
8Hddgb5yNa/U7Tc7uSEWuNZOr8BdwJk6SvlNoCRLaQxPk/jJavrc58Uuw85SH4A1G5
BZLhZi6YF/ydgkKwyis9Gb+JM3j7r79raATQ7S4mL39tHuQf2cZPZrGrAoSwXAoOlG
CNWZs6V3kT5//TZRIvcd7YQpg2vkAdikIijbmDYhb8Wy7jbsnekm3f9cSN29hMN0HP
PkA07oenSpjrelS7wbxqcTQwszKO+gOidTdfYJK/ZiXMM4HlOVzY3tmD9iZJVobuFP
KhTSbV9xIByPg==
Date: Fri, 17 Jan 2025 20:52:58 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75632: 31.0.50; igc: Crash report
Message-ID: <87o705f9id.fsf@HIDDEN>
In-Reply-To: <86y0z9chcb.fsf@HIDDEN>
References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN>
<877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN>
<86y0z9chcb.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 7347f070edb6d9183bd89f20b0cb87adb4735f5f
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75632
Cc: yantar92@HIDDEN, 75632 <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.0 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Resent-To: bug-gnu-emacs@HIDDEN
>> Cc: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>,
>> 75632-done <at> debbugs.gnu.org
>> Date: Fri, 17 Jan 2025 15:26:10 +0000
>> From: Pip Cet via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> "Ihor Radchenko" <yantar92@HIDDEN> writes:
>>
>> > Pip Cet <pipcet@HIDDEN> writes:
>> >
>> >> "Ihor Radchenko" <yantar92@HIDDEN> writes:
>> >>
>> >>> Just got the following:
>> >>
>> >> Yes, that's the signal handling bug. I'm not entirely sure why we
>> >> removed the fix that was in scratch/igc, but we did, so we need anoth=
er
>> >> one.
>> >> ...
>> >> to handle_user_signal, which will silently ignore SIGUSR* received wh=
ile
>> >> MPS may have locked the arena.
>> >
>> > I indeed sent SIGUSR2 just before I saw the crash.
>>
>> It'd be nice if that simply worked. I think debugging with SIGUSR* is
>> important, so I've pushed a fix (and I'm closing this bug; if further
>> discussion is needed, feel free to revert and reopen).
>
> This breaks the MS-Windows build: temacs crashes as below:
Sorry. Can you try the fix I just pushed? While I arrived at that
independently (I was about to push when I got your email), I believe it
explains your crash as well.
> (gdb) bt
> #0 terminate_due_to_signal (sig=3Dsig@entry=3D22,
> backtrace_limit=3Dbacktrace_limit@entry=3D2147483647) at emacs.c:43=
2
> #1 0x00f836f4 in die (
> msg=3Dmsg@entry=3D0x15369e9 <gdb_make_enums_visible+1745> "should_e=
nd >=3D end",
> file=3Dfile@entry=3D0x1536431 <gdb_make_enums_visible+281> "pdumper=
.c",
> line=3Dline@entry=3D939) at alloc.c:8388
> #2 0x00f88e8a in dump_igc_finish_obj (ctx=3Dctx@entry=3D0xbfebd8) at p=
dumper.c:939
This function calls igc_dump_finish_obj, which returns 0 because the GC
header for the static subr hasn't been initialized, and then causes the
assertion error.
> The following patch seems to fix that, but I'm not sure it's the
> correct fix. Can you explain why we need to add-variable-watcher for
> this in init_keyboard, in particular in temacs?
I'm not sure what you are suggesting here. Is there a good place that
is initialized only in the !pdumper || !temacs case?
> since init_keyboard
> is called both in temacs and in emacs, it sounds like the code, when
> called in emacs, will try to free memory that was malloced in temacs,
> is that right?
I don't think so, but it might call Fadd_variable_watcher twice. We
should avoid that.
> diff --git a/src/keyboard.c b/src/keyboard.c
> index 82505e7..a5d85e9 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -12817,6 +12817,7 @@ init_keyboard (void)
> #endif
>
> #ifdef HAVE_MPS
> + if (initialized)
> {
> Lisp_Object watcher;
I can add that (with a FIXME comment because it breaks the !pdumper
case, which is currently an #error but appears to work).
Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.
Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 20:32:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 15:32:03 2025
Received: from localhost ([127.0.0.1]:38962 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tYt0b-0005UT-Ul
for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 15:32:03 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:55462)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYt0Y-0005U7-MW
for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 15:32:00 -0500
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 1tYt0R-0001NR-My; Fri, 17 Jan 2025 15:31:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=LrE83PFaqomoHdVhDngBCNtijMd3XXm2CikGhpHyDgA=; b=fiovBwVCx7Mn38T4Jq+g
xGTym2DIyZRb3q5SXdzSLCZjoCwbkuLd3Nb5zgvQLk1L/IbiawE6Xur8r0UYPTjzTFMolIQrP2yCM
2W16E9tIX0K9h4DiXS3Lg2E4m1J9pUq6b0LFrKYObGPb+k7IfG8Oate+jQRsgg1tJGVhbGdEhgL3y
S1tmm2caOSW+AG9epSeo/iNHBzA92tOA67v7lX9W4FeoWkCpAdqb9wETOrLq2EeMAyNL5cyj2jlyX
VhKSFJNyYKu6KxpiCmz3Cu45t/3/wps4C0jlfnpK7VEqu3TRKF9zgDbLcbqAdOv3nq0lIa7n8FLEr
cFyRtRVScpKYTA==;
Date: Fri, 17 Jan 2025 22:31:48 +0200
Message-Id: <86y0z9chcb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <878qr9ihry.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#75632: 31.0.50; igc: Crash report
References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN>
<877c6to5v8.fsf@localhost> <878qr9ihry.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75632
Cc: yantar92@HIDDEN, 75632 <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: -3.3 (---)
> Resent-To: bug-gnu-emacs@HIDDEN
> Cc: Gerd Möllmann <gerd.moellmann@HIDDEN>,
> 75632-done <at> debbugs.gnu.org
> Date: Fri, 17 Jan 2025 15:26:10 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> "Ihor Radchenko" <yantar92@HIDDEN> writes:
>
> > Pip Cet <pipcet@HIDDEN> writes:
> >
> >> "Ihor Radchenko" <yantar92@HIDDEN> writes:
> >>
> >>> Just got the following:
> >>
> >> Yes, that's the signal handling bug. I'm not entirely sure why we
> >> removed the fix that was in scratch/igc, but we did, so we need another
> >> one.
> >> ...
> >> to handle_user_signal, which will silently ignore SIGUSR* received while
> >> MPS may have locked the arena.
> >
> > I indeed sent SIGUSR2 just before I saw the crash.
>
> It'd be nice if that simply worked. I think debugging with SIGUSR* is
> important, so I've pushed a fix (and I'm closing this bug; if further
> discussion is needed, feel free to revert and reopen).
This breaks the MS-Windows build: temacs crashes as below:
Loading loadup.el (source)...
Dump mode: pbootstrap
Using load-path (d:/gnu/git/emacs/feature/lisp d:/gnu/git/emacs/feature/lisp/emacs-lisp d:/gnu/git/emacs/feature/lisp/progmodes d:/gnu/git/emacs/feature/lisp/language d:/gnu/git/emacs/feature/lisp/international d:/gnu/git/emacs/feature/lisp/textmodes d:/gnu/git/emacs/feature/lisp/vc)
Loading emacs-lisp/debug-early...
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading keymap...
Loading version...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading international/mule...
Loading international/mule-conf...
Loading env...
Loading format...
Loading bindings...
Loading window...
Loading files...
Loading emacs-lisp/macroexp...
Loading cus-face...
Loading faces...
Loading loaddefs...
Loading d:/gnu/git/emacs/feature/lisp/theme-loaddefs.el (source)...
Loading button...
Loading emacs-lisp/cl-preloaded...
Loading emacs-lisp/oclosure...
Loading obarray...
Loading abbrev...
Loading help...
Loading jka-cmpr-hook...
Loading epa-hook...
Loading international/mule-cmds...
Loading case-table...
Loading d:/gnu/git/emacs/feature/lisp/international/charprop.el (source)...
Loading international/characters...
Loading international/charscript...
Loading international/emoji-zwj...
Loading composite...
Loading language/chinese...
Loading language/cyrillic...
Loading language/indian...
Loading language/sinhala...
Loading language/english...
Loading language/ethiopic...
Loading language/european...
Loading language/czech...
Loading language/slovak...
Loading language/romanian...
Loading language/greek...
Loading language/hebrew...
Loading international/cp51932...
Loading international/eucjp-ms...
Loading language/japanese...
Loading language/korean...
Loading language/lao...
Loading language/tai-viet...
Loading language/thai...
Loading language/tibetan...
Loading language/vietnamese...
Loading language/misc-lang...
Loading language/utf-8-lang...
Loading language/georgian...
Loading language/khmer...
Loading language/burmese...
Loading language/cham...
Loading language/philippine...
Loading language/indonesian...
Loading indent...
Loading emacs-lisp/cl-generic...
Loading simple...
Loading emacs-lisp/seq...
Loading emacs-lisp/nadvice...
Loading minibuffer...
Loading frame...
Loading startup...
Loading term/tty-colors...
Loading font-core...
Loading emacs-lisp/syntax...
Loading font-lock...
Loading jit-lock...
Loading mouse...
Loading scroll-bar...
Loading select...
Loading emacs-lisp/timer...
Loading emacs-lisp/easymenu...
Loading isearch...
Loading rfn-eshadow...
Loading menu-bar...
Loading tab-bar...
Loading emacs-lisp/lisp...
Loading textmodes/page...
Loading register...
Loading textmodes/paragraphs...
Loading progmodes/prog-mode...
Loading emacs-lisp/lisp-mode...
Loading textmodes/text-mode...
Loading textmodes/fill...
Loading newcomment...
Loading replace...
Loading emacs-lisp/tabulated-list...
Loading buff-menu...
Loading fringe...
Loading emacs-lisp/regexp-opt...
Loading image...
Loading international/fontset...
Loading dnd...
Loading tool-bar...
Loading term/common-win...
Loading w32-vars...
Loading term/w32-win...
Loading disp-table...
Loading w32-fns...
Loading ls-lisp...
Loading dos-w32...
Loading touch-screen...
Loading mwheel...
Loading progmodes/elisp-mode...
Loading emacs-lisp/float-sup...
Loading vc/vc-hooks...
Loading vc/ediff-hook...
Loading uniquify...
Loading electric...
Loading paren...
Loading emacs-lisp/shorthands...
Loading emacs-lisp/eldoc...
Loading emacs-lisp/cconv...
Loading cus-start...
Loading tooltip...
Loading international/iso-transl...
Loading emacs-lisp/rmc...
Loading d:/gnu/git/emacs/feature/lisp/leim/leim-list.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Dumping under the name bootstrap-emacs.pdmp
Dumping fingerprint: 18388262a2082a9a0cae7f9f7b2f954b596ec03f060bf8e73cbd63063b9a1d95
pdumper.c:939: Emacs fatal error: assertion failed: should_end >= end
Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
432 {
(gdb) bt
#0 terminate_due_to_signal (sig=sig@entry=22,
backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
#1 0x00f836f4 in die (
msg=msg@entry=0x15369e9 <gdb_make_enums_visible+1745> "should_end >= end",
file=file@entry=0x1536431 <gdb_make_enums_visible+281> "pdumper.c",
line=line@entry=939) at alloc.c:8388
#2 0x00f88e8a in dump_igc_finish_obj (ctx=ctx@entry=0xbfebd8) at pdumper.c:939
#3 0x00f8caca in dump_object_finish (sz=40, out=0xbfe990, ctx=0xbfebd8)
at pdumper.c:1003
#4 dump_subr (subr=0x11611e0 <Swatch_debug_on_event.43963>, ctx=0xbfebd8)
at pdumper.c:3093
#5 dump_vectorlike (offset=6440296, lv=XIL(0x11611e5), ctx=0xbfebd8)
at pdumper.c:3187
#6 dump_object (ctx=ctx@entry=0xbfebd8, object=XIL(0x11611e5))
at pdumper.c:3318
#7 0x00f8e7f4 in dump_drain_copied_objects (ctx=0xbfebd8) at pdumper.c:3539
#8 Fdump_emacs_portable (filename=<optimized out>,
track_referrers=<optimized out>) at pdumper.c:4524
#9 0x00fb3ecc in eval_sub (form=XIL(0xc35cedb)) at eval.c:2623
#10 0x00fb3cd9 in eval_sub (form=XIL(0xc35ce1b)) at eval.c:2571
#11 0x00fb514a in Fprogn (body=XIL(0xc35d0e3)) at eval.c:452
#12 Flet (args=<optimized out>) at eval.c:1122
#13 0x00fb3cd9 in eval_sub (form=XIL(0xc35cd33)) at eval.c:2571
#14 0x00fb58cc in Funwind_protect (args=XIL(0xc35d0f3)) at lisp.h:1563
#15 0x00fb3cd9 in eval_sub (form=XIL(0xc35cd23)) at eval.c:2571
#16 0x00fb514a in Fprogn (body=XIL(0)) at eval.c:452
#17 Flet (args=<optimized out>) at eval.c:1122
#18 0x00fb3cd9 in eval_sub (form=XIL(0xc35ccf3)) at eval.c:2571
#19 0x00fb514a in Fprogn (body=XIL(0xc35dbb3)) at eval.c:452
#20 Flet (args=<optimized out>) at eval.c:1122
#21 0x00fb3cd9 in eval_sub (form=XIL(0xc35c793)) at eval.c:2571
#22 0x00fb3cd9 in eval_sub (form=XIL(0xc35c773)) at eval.c:2571
#23 0x00fb48b4 in Fprogn (body=XIL(0)) at eval.c:452
#24 Fif (args=XIL(0xc35c32b)) at eval.c:408
#25 0x00fb3cd9 in eval_sub (form=form@entry=XIL(0xc35c25b)) at eval.c:2571
#26 0x00ff023c in readevalloop (readcharfun=readcharfun@entry=XIL(0x6120),
infile0=infile0@entry=0xbff638,
sourcename=sourcename@entry=XIL(0xb04a364),
printflag=printflag@entry=false, unibyte=unibyte@entry=XIL(0),
readfun=readfun@entry=XIL(0), start=start@entry=XIL(0),
end=<optimized out>, end@entry=XIL(0)) at lread.c:2540
#27 0x00ff0cd9 in Fload (file=XIL(0xb04a004), noerror=XIL(0),
nomessage=XIL(0), nosuffix=XIL(0), must_suffix=<optimized out>)
at lisp.h:1229
#28 0x00fb3e69 in eval_sub (form=form@entry=XIL(0xb04a02b)) at eval.c:2634
#29 0x00fb5e32 in Feval (form=XIL(0xb04a02b), lexical=lexical@entry=XIL(0x20))
at eval.c:2479
#30 0x00f0ef8b in top_level_2 () at lisp.h:1229
#31 0x00fae15b in internal_condition_case (
bfun=bfun@entry=0xf0ef2c <top_level_2>, handlers=handlers@entry=XIL(0x60),
hfun=hfun@entry=0xf18d54 <cmd_error>) at eval.c:1627
#32 0x00f0f6b8 in top_level_1 (ignore=XIL(0)) at lisp.h:1229
#33 0x00fae077 in internal_catch (tag=tag@entry=XIL(0xc560),
func=func@entry=0xf0f68c <top_level_1>, arg=arg@entry=XIL(0))
at eval.c:1306
#34 0x00f0ed3f in command_loop () at lisp.h:1229
#35 0x00f188fa in recursive_edit_1 () at keyboard.c:760
#36 0x00f18c01 in Frecursive_edit () at keyboard.c:843
#37 0x0115fc05 in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2658
Lisp Backtrace:
"dump-emacs-portable" (0xbfed90)
"if" (0xbfee1c)
"let" (0xbfef1c)
"unwind-protect" (0xbfefcc)
"let" (0xbff0bc)
"let" (0xbff1ac)
"if" (0xbff23c)
"if" (0xbff2ec)
"load" (0xbff8e0)
(gdb) up
#1 0x00f836f4 in die (
msg=msg@entry=0x15369e9 <gdb_make_enums_visible+1745> "should_end >= end",
file=file@entry=0x1536431 <gdb_make_enums_visible+281> "pdumper.c",
line=line@entry=939) at alloc.c:8388
8388 terminate_due_to_signal (SIGABRT, INT_MAX);
(gdb)
#2 0x00f88e8a in dump_igc_finish_obj (ctx=ctx@entry=0xbfebd8) at pdumper.c:939
939 eassert (should_end >= end);
(gdb) p should_end
$1 = <optimized out>
(gdb) p end
$2 = 0x1b5c35b0 ""
(gdb) p igc_dump_finish_obj (ctx->igc_obj_dumped, ctx->igc_type, base, end)
value has been optimized out
(gdb) p base
$3 = <optimized out>
p igc_dump_finish_obj (ctx->igc_obj_dumped, ctx->igc_type, (char *) ctx->buf + ctx->igc_base_offset, end)
$4 = 0x1b5c3588 ""
The following patch seems to fix that, but I'm not sure it's the
correct fix. Can you explain why we need to add-variable-watcher for
this in init_keyboard, in particular in temacs? since init_keyboard
is called both in temacs and in emacs, it sounds like the code, when
called in emacs, will try to free memory that was malloced in temacs,
is that right?
diff --git a/src/keyboard.c b/src/keyboard.c
index 82505e7..a5d85e9 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -12817,6 +12817,7 @@ init_keyboard (void)
#endif
#ifdef HAVE_MPS
+ if (initialized)
{
Lisp_Object watcher;
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.
Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 16:48:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 11:48:37 2025
Received: from localhost ([127.0.0.1]:38661 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tYpWO-00071Y-FR
for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 11:48:37 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:58398)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tYpWH-000716-T0
for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 11:48:33 -0500
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 1tYpWC-00014o-DD; Fri, 17 Jan 2025 11:48:24 -0500
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=/q2aWTUFld2GMn3vpxPQkoa3GYMMD9QkFnruqU8T8LM=; b=oP3InG37ISWn
zkPBkErkrj90Iw/gEbKGa4ZDlPcI+H3jBImPlEtiltrxTrMT4q2Xa1GH8zJTRxz3F+BWZZoV1bfO6
j8bKN5nFydeeYGDRSsInFSi7W3BeL2EcRRyuoUo8jub6Lj6UbxgYOyDj2DdtHz6SfE4rEAFvkcmUF
NHd0l9a5nRivxW+4uB1wBNImIXQSE0nvgETkqnz/3PX65xUzWXCfautRwSWdpV8xg9UcsUP8peKhH
YSyqBOgoVQSYk3A5QXl/bP8X1Nr5FbsWw//9f+ZHYh0AUPmRjkfc8po+hTNQJL31dSaFc3mkWSr/2
OBrNUZHzr7Tfj5YJfUwmaA==;
Date: Fri, 17 Jan 2025 18:48:21 +0200
Message-Id: <86cygle696.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <87a5bpo6bv.fsf@localhost> (message from Ihor Radchenko on Fri,
17 Jan 2025 14:36:36 +0000)
Subject: Re: bug#75632: 31.0.50; igc: Crash report
References: <87a5bpo6bv.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75632
Cc: 75632 <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: -3.3 (---)
> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Fri, 17 Jan 2025 14:36:36 +0000
>
> Just got the following:
>
>
> lockix.c:126: Emacs fatal error: assertion failed: res == 0
> [Switching to Thread 0x7ffff2b71e00 (LWP 11068)]
>
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
> 432 {
> (gdb) bt
> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
> #1 0x00005555557e24fb in set_state (state=IGC_STATE_DEAD) at igc.c:975
> #2 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at igc.c:276
> #3 0x000055555585f049 in mps_lib_assert_fail (condition=0x5555558c0763 "res == 0", line=126, file=0x5555558c074d "lockix.c") at /home/yantar92/Dist/mps/code/mpsliban.c:87
> #4 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126
> #5 0x000055555585f27d in ArenaEnterLock (arena=0x7ffff7fbe000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576
> #6 0x000055555588812e in ArenaEnter (arena=0x7ffff7fbe000) at /home/yantar92/Dist/mps/code/global.c:553
> #7 ArenaAccess (addr=0x7fff9d8709e0, mode=mode@entry=3, context=context@entry=0x7fffffff4650) at /home/yantar92/Dist/mps/code/global.c:655
> #8 0x0000555555893432 in sigHandle (sig=<optimized out>, info=0x7fffffff4970, uap=0x7fffffff4840) at /home/yantar92/Dist/mps/code/protsgix.c:97
> #9 0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
> #10 0x00005555556d2273 in SDATA (string=<optimized out>) at /home/yantar92/Git/emacs/src/lisp.h:1758
> #11 SSDATA (string=<optimized out>) at /home/yantar92/Git/emacs/src/lisp.h:1764
> #12 handle_user_signal (sig=sig@entry=12) at keyboard.c:8315
> #13 0x00005555556f1678 in deliver_process_signal (sig=12, handler=handler@entry=0x5555556d2210 <handle_user_signal>) at sysdep.c:1757
> #14 0x00005555556d1134 in deliver_user_signal (sig=<optimized out>) at keyboard.c:8352
Looks like Emacs got SIGUSR1 or SIGUSR2? How come?
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.Received: (at 75632-done) by debbugs.gnu.org; 17 Jan 2025 15:26:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 10:26:26 2025 Received: from localhost ([127.0.0.1]:38538 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tYoEs-00031n-58 for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 10:26:26 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:33571) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tYoEn-00030z-Tg for 75632-done <at> debbugs.gnu.org; Fri, 17 Jan 2025 10:26:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737127573; x=1737386773; bh=5gBCkcml9ymLxbnvT7U6uHd54jCyVk+uEaCtRi//U0k=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=QraR8Q1FdnldizXtK2j1Amdu1UJIsUnDCbokgBTMSYyr7wo8+jcccBfCsLRAqLbcQ N0eBWBQvVz2A9xVpfMmCh/xK/6oqipK31mzXYOOEw7jnWERKZ/KINIItqBvN4W5vAM GkEt78tS+60j1d7zglShbwBbOOtmo/9ebYHcohx9b2xNqptVHmFIJbIb//L4uQzfdh DUR25Cvem5NPlWsrn4lQYuKxKJ/aOTssi5jKJ/x+0SSmEZ0c/zLREjzc2vtSbfLuI2 xvZU++VIgFVSKdLoj+fjUvVYjOHk82uTii4UHu6YmWTarkaJTHjEgZHCS6vZZgyUPQ jJqLoO6hQnN1g== Date: Fri, 17 Jan 2025 15:26:10 +0000 To: Ihor Radchenko <yantar92@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <878qr9ihry.fsf@HIDDEN> In-Reply-To: <877c6to5v8.fsf@localhost> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> <877c6to5v8.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b8db2444f672900a163cabcccaaf9fc237835811 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632-done Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, 75632-done <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.0 (-) "Ihor Radchenko" <yantar92@HIDDEN> writes: > Pip Cet <pipcet@HIDDEN> writes: > >> "Ihor Radchenko" <yantar92@HIDDEN> writes: >> >>> Just got the following: >> >> Yes, that's the signal handling bug. I'm not entirely sure why we >> removed the fix that was in scratch/igc, but we did, so we need another >> one. >> ... >> to handle_user_signal, which will silently ignore SIGUSR* received while >> MPS may have locked the arena. > > I indeed sent SIGUSR2 just before I saw the crash. It'd be nice if that simply worked. I think debugging with SIGUSR* is important, so I've pushed a fix (and I'm closing this bug; if further discussion is needed, feel free to revert and reopen). > For some context (maybe irrelevant), Emacs hung while performing magit > commit (C-c C-c in magit commit buffer; and the commit was actually > written before the hang). It only ever happened for me on igc branch. Thanks! Too bad we lost that backtrace, then. If it happens again, please let us know! (I'm using magit, and I know it waits for subprocesses, so I'll go over the SIGCHLD handling code to ensure we never drop one of them). Pip
Ihor Radchenko <yantar92@HIDDEN>:Pip Cet <pipcet@HIDDEN>:Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 14:44:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 09:44:39 2025 Received: from localhost ([127.0.0.1]:36537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tYnaR-0000Kc-0w for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:44:39 -0500 Received: from mout01.posteo.de ([185.67.36.65]:59691) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1tYnaM-0000Ja-PH for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:44:36 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 13DFC240027 for <75632 <at> debbugs.gnu.org>; Fri, 17 Jan 2025 15:44:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1737125067; bh=UvS08/wqEHHKVq0dP1iOWxp9++5K67h32jwuu5HcdD4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=gKs4PatIsGXaQUqvzXze6WQHEn0Y4gKEdPNR2ohB91C2Euf9n+pOk3dsiJL5CBJHc 8/Tia05Wtd/pfyYqCprC+ByI6aKon4IkxMPO+KGQxU6ghEHi3IhU/PKJveFgiIE+KV T7wgEyBhnx0fqFFjIErpT3rvJ9JTDgsabMn/dwcvZKWVpa2oNdST/sYP0ammXfkaPk kPZ7YzxKqsAPAJmvI+sUhBgztKmourk0emCtHM98Q0aSelcCU+OR0t33Kej1b+G7PY frnfB/uXbCdpCIwcK1xnMiC87hPO7/PdhIIzOLf2clwcaff2TcNnXoxR1m80vC/lkj aqCOADc+IfRYQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YZMvG382jz9rxD; Fri, 17 Jan 2025 15:44:26 +0100 (CET) From: Ihor Radchenko <yantar92@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report In-Reply-To: <87cyglijvd.fsf@HIDDEN> References: <87a5bpo6bv.fsf@localhost> <87cyglijvd.fsf@HIDDEN> Date: Fri, 17 Jan 2025 14:46:35 +0000 Message-ID: <877c6to5v8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75632 Cc: 75632 <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: -3.3 (---) Pip Cet <pipcet@HIDDEN> writes: > "Ihor Radchenko" <yantar92@HIDDEN> writes: > >> Just got the following: > > Yes, that's the signal handling bug. I'm not entirely sure why we > removed the fix that was in scratch/igc, but we did, so we need another > one. > ... > to handle_user_signal, which will silently ignore SIGUSR* received while > MPS may have locked the arena. I indeed sent SIGUSR2 just before I saw the crash. For some context (maybe irrelevant), Emacs hung while performing magit commit (C-c C-c in magit commit buffer; and the commit was actually written before the hang). It only ever happened for me on igc branch. -- 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#75632; Package emacs.
Full text available.Received: (at 75632) by debbugs.gnu.org; 17 Jan 2025 14:41:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 09:41:09 2025 Received: from localhost ([127.0.0.1]:36524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tYnX2-0000CH-Gl for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:41:08 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:42391) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tYnWz-0000Bb-Hg for 75632 <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:41:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737124858; x=1737384058; bh=AINF/gjPSdYr0vk8EJzWgixc0b1lMqkkOGewxldSBUY=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=oKaSvOqjDUpo53V2e629PC03PveXx7Vnaq8J/ScT8taARCADk3T67zRDXqn+w4kHL 8YU3q/H3XTdpiMMRqZCVRFz+xC1pkE3AjUhy+OAbNB1MPQ+72qrVwHEzccr2ShZ1gQ L/boCjBmcO929eHBR3dV0H8DCQSs4bBcG6pmUAilz880Uex6pJo/hDBh9ZGqokDwUe skN0ngfbWK4lhWdXoKNCBDSxVyb2MJiWNp4MSdwRtr8PHIyWv+VUbKQtrSiMSXcBj+ nLqVAvl0HcsfIyUbF278OH2oJbAW8biuHPTUDBA3hcucxzI3VY5CWRHyqyMBbBssVc 5rX6MvQKxZgSg== Date: Fri, 17 Jan 2025 14:40:54 +0000 To: Ihor Radchenko <yantar92@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75632: 31.0.50; igc: Crash report Message-ID: <87cyglijvd.fsf@HIDDEN> In-Reply-To: <87a5bpo6bv.fsf@localhost> References: <87a5bpo6bv.fsf@localhost> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2beed9f2243f9fce4d6a4cb24dc60faadec6c397 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75632 Cc: 75632 <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.0 (-) "Ihor Radchenko" <yantar92@HIDDEN> writes: > Just got the following: Yes, that's the signal handling bug. I'm not entirely sure why we removed the fix that was in scratch/igc, but we did, so we need another one. For a quick fix, you can add if (igc_busy_p ()) return; to handle_user_signal, which will silently ignore SIGUSR* received while MPS may have locked the arena. Pip
bug-gnu-emacs@HIDDEN:bug#75632; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 17 Jan 2025 14:34:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 17 09:34:45 2025
Received: from localhost ([127.0.0.1]:36511 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tYnQq-0008Gf-8c
for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:34:45 -0500
Received: from lists.gnu.org ([2001:470:142::17]:33672)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <yantar92@HIDDEN>)
id 1tYnQl-0008GO-Ey
for submit <at> debbugs.gnu.org; Fri, 17 Jan 2025 09:34:41 -0500
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 1tYnQe-0007NW-Vr
for bug-gnu-emacs@HIDDEN; Fri, 17 Jan 2025 09:34:33 -0500
Received: from mout01.posteo.de ([185.67.36.65])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yantar92@HIDDEN>)
id 1tYnQa-0002ES-KG
for bug-gnu-emacs@HIDDEN; Fri, 17 Jan 2025 09:34:32 -0500
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 818DE240027
for <bug-gnu-emacs@HIDDEN>; Fri, 17 Jan 2025 15:34:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1737124465; bh=y37JZ411xqFB6ytK0GDe7gsUrZI2euopPHM3w9D5zb0=;
h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From;
b=iCtWSabLCymZ081yQ5zyWBj3Ro+qdLghUgcPN9MJWkgwIJABYZ10PcAIP+ULQCJbt
9HXYf8DP+dUnsIrJGbIBgfKq0objW1c66dskTMoyMgjT15PjQ8dsj3gnRnP2VX4pvy
5eCYu2S1yVe8UBSVgIRb/I67m4iE5jQJdZbXQr80t+58LDlms1gb9tjW/mIHwfK203
kChumkb5jBNDVtNLPoNqyvHxu8DkayANDi/cO8S+pdAQLHQOBBwIoonDRLdCE0B8EO
JcbmQsmZQ/aR2qyprSsxAkIrkVGptXrKLXcB7qZwEWygBtdyftAw2knjy5mfd6J62r
dhDOZCnodH8+g==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4YZMgh74TJz6txZ
for <bug-gnu-emacs@HIDDEN>; Fri, 17 Jan 2025 15:34:24 +0100 (CET)
From: Ihor Radchenko <yantar92@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; igc: Crash report
X-Debbugs-Cc:
Date: Fri, 17 Jan 2025 14:36:36 +0000
Message-ID: <87a5bpo6bv.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@HIDDEN;
helo=mout01.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_NONE=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 (/)
Just got the following:
lockix.c:126: Emacs fatal error: assertion failed: res == 0
[Switching to Thread 0x7ffff2b71e00 (LWP 11068)]
Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
432 {
(gdb) bt
#0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:432
#1 0x00005555557e24fb in set_state (state=IGC_STATE_DEAD) at igc.c:975
#2 igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at igc.c:276
#3 0x000055555585f049 in mps_lib_assert_fail (condition=0x5555558c0763 "res == 0", line=126, file=0x5555558c074d "lockix.c") at /home/yantar92/Dist/mps/code/mpsliban.c:87
#4 LockClaim (lock=0x7fffe8000110) at /home/yantar92/Dist/mps/code/lockix.c:126
#5 0x000055555585f27d in ArenaEnterLock (arena=0x7ffff7fbe000, recursive=0) at /home/yantar92/Dist/mps/code/global.c:576
#6 0x000055555588812e in ArenaEnter (arena=0x7ffff7fbe000) at /home/yantar92/Dist/mps/code/global.c:553
#7 ArenaAccess (addr=0x7fff9d8709e0, mode=mode@entry=3, context=context@entry=0x7fffffff4650) at /home/yantar92/Dist/mps/code/global.c:655
#8 0x0000555555893432 in sigHandle (sig=<optimized out>, info=0x7fffffff4970, uap=0x7fffffff4840) at /home/yantar92/Dist/mps/code/protsgix.c:97
#9 0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
#10 0x00005555556d2273 in SDATA (string=<optimized out>) at /home/yantar92/Git/emacs/src/lisp.h:1758
#11 SSDATA (string=<optimized out>) at /home/yantar92/Git/emacs/src/lisp.h:1764
#12 handle_user_signal (sig=sig@entry=12) at keyboard.c:8315
#13 0x00005555556f1678 in deliver_process_signal (sig=12, handler=handler@entry=0x5555556d2210 <handle_user_signal>) at sysdep.c:1757
#14 0x00005555556d1134 in deliver_user_signal (sig=<optimized out>) at keyboard.c:8352
#15 0x00007ffff2c41100 in <signal handler called> () at /lib64/libc.so.6
#16 0x00007ffff2d189ab in mprotect () at /lib64/libc.so.6
#17 0x000055555588183d in ProtSet (base=0x7ffe4c324000, limit=<optimized out>, mode=0) at /home/yantar92/Dist/mps/code/protix.c:105
#18 0x000055555588b9dc in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, arena=arena@entry=0x7ffff7fbe000, seg=seg@entry=0x7ffe4803e5f8) at /home/yantar92/Dist/mps/code/trace.c:1204
#19 0x000055555588bbfa in traceScanSeg (ts=1, rank=1, arena=0x7ffff7fbe000, seg=0x7ffe4803e5f8) at /home/yantar92/Dist/mps/code/trace.c:1267
#20 0x000055555588c5d4 in TraceAdvance (trace=trace@entry=0x7ffff7fbeaa8) at /home/yantar92/Dist/mps/code/trace.c:1728
#21 0x000055555588ccd4 in TracePoll
(workReturn=workReturn@entry=0x7fffffff58d0, collectWorldReturn=collectWorldReturn@entry=0x7fffffff58cc, globals=globals@entry=0x7ffff7fbe008, collectWorldAllowed=<optimized out>)
at /home/yantar92/Dist/mps/code/trace.c:1849
#22 0x000055555588cf1b in ArenaPoll (globals=globals@entry=0x7ffff7fbe008) at /home/yantar92/Dist/mps/code/global.c:745
#23 0x000055555588d30a in mps_ap_fill (p_o=p_o@entry=0x7fffffff5a40, mps_ap=mps_ap@entry=0x7fffe8001980, size=size@entry=24) at /home/yantar92/Dist/mps/code/mpsi.c:1097
#24 0x00005555557ddf28 in alloc_impl (size=24, type=IGC_OBJ_CONS, ap=0x7fffe8001980) at igc.c:3956
#25 0x00005555557de04c in alloc (size=size@entry=24, type=type@entry=IGC_OBJ_CONS) at igc.c:3984
#26 0x00005555557e0964 in igc_make_cons (car=car@entry=XIL(0x7ffefc1c18a5), cdr=XIL(0x7ffdf8565feb)) at igc.c:4013
#27 0x0000555555734ee8 in Fcons (car=car@entry=XIL(0x7ffefc1c18a5), cdr=<optimized out>) at alloc.c:2958
#28 0x0000555555752a84 in save_restriction_save () at editfns.c:3097
#29 0x00005555557a3267 in helper_save_restriction () at comp.c:5128
#30 0x00007fffdc3efc22 in F6f72672d666f6c642d636f72652d6765742d666f6c64696e672d73706563_org_fold_core_get_folding_spec_0 ()
at /home/yantar92/.emacs.d/eln-cache/31.0.50-fc0e2b3f/org-fold-core-7b3a75f5-931c108c.eln
#31 0x0000555555758fb3 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffdedff0c0) at eval.c:3178
#32 0x000055555579fdaf 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=0x7fffffff5e68)
at /home/yantar92/Git/emacs/src/lisp.h:2332
#33 0x000055555575ab86 in funcall_lambda (fun=XIL(0x7fff9ebde0b5), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffff5e68) at eval.c:3267
#34 0x000055555575af3b in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff5e68) at eval.c:3059
#35 0x0000555555757198 in Ffuncall (nargs=2, args=0x7fffffff5e60) at eval.c:3108
#36 0x00007fffdf8c6a6f in F666f6e742d6c6f636b2d666f6e746966792d6b6579776f7264732d726567696f6e_font_lock_fontify_keywords_region_0 ()
at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln
#37 0x0000555555758fca in funcall_subr (subr=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffff6188) at eval.c:3180
#38 0x000055555575b08a in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffff6188) at /home/yantar92/Git/emacs/src/lisp.h:2332
#39 0x0000555555757198 in Ffuncall (nargs=4, args=0x7fffffff6180) at eval.c:3108
#40 0x00007fffdf8c2740 in F666f6e742d6c6f636b2d64656661756c742d666f6e746966792d726567696f6e_font_lock_default_fontify_region_0 ()
at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln
#41 0x0000555555758fca in funcall_subr (subr=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffff6308) at eval.c:3180
#42 0x000055555575b08a in funcall_general (fun=<optimized out>, numargs=numargs@entry=3, args=args@entry=0x7fffffff6308) at /home/yantar92/Git/emacs/src/lisp.h:2332
#43 0x0000555555757198 in Ffuncall (nargs=4, args=0x7fffffff6300) at eval.c:3108
#44 0x00007fffdf8c1735 in F666f6e742d6c6f636b2d666f6e746966792d726567696f6e_font_lock_fontify_region_0 ()
at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/font-lock-895216f6-4021c0ad.eln
#45 0x0000555555758fca in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffdedff040) at eval.c:3180
#46 0x000055555579fdaf 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=0x7fffffff6608)
at /home/yantar92/Git/emacs/src/lisp.h:2332
#47 0x000055555575ab86 in funcall_lambda (fun=XIL(0x7ffdf852f91d), nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffff6608) at eval.c:3267
#48 0x000055555575af3b in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff6608) at eval.c:3059
--Type <RET> for more, q to quit, c to continue without paging--c
#49 0x0000555555757198 in Ffuncall (nargs=2, args=args@entry=0x7fffffff6600) at eval.c:3108
#50 0x000055555575777d in run_hook_wrapped_funcall (nargs=<optimized out>, args=0x7fffffff6600) at eval.c:2887
#51 0x00005555557562b9 in run_hook_with_args (nargs=2, args=0x7fffffff6600, funcall=funcall@entry=0x55555575775c <run_hook_wrapped_funcall>) at eval.c:2968
#52 0x000055555575648e in Frun_hook_wrapped (nargs=<optimized out>, args=<optimized out>) at eval.c:2902
#53 0x00007fffdf89fafa in F6a69742d6c6f636b2d2d72756e2d66756e6374696f6e73_jit_lock__run_functions_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln
#54 0x0000555555758fb3 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffff67e8) at eval.c:3178
#55 0x000055555575b08a in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffff67e8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#56 0x0000555555757198 in Ffuncall (nargs=3, args=0x7fffffff67e0) at eval.c:3108
#57 0x00007fffdf8a03aa in F6a69742d6c6f636b2d666f6e746966792d6e6f77_jit_lock_fontify_now_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln
#58 0x0000555555758fb3 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffff69a8) at eval.c:3178
#59 0x000055555575b08a in funcall_general (fun=<optimized out>, numargs=numargs@entry=2, args=args@entry=0x7fffffff69a8) at /home/yantar92/Git/emacs/src/lisp.h:2332
#60 0x0000555555757198 in Ffuncall (nargs=3, args=0x7fffffff69a0) at eval.c:3108
#61 0x00007fffdf89f837 in F6a69742d6c6f636b2d66756e6374696f6e_jit_lock_function_0 () at /home/yantar92/Git/emacs/src/../native-lisp/31.0.50-fc0e2b3f/preloaded/jit-lock-8a988e43-86e09700.eln
#62 0x0000555555758fa0 in funcall_subr (subr=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff6b68) at eval.c:3176
#63 0x000055555575b08a in funcall_general (fun=<optimized out>, numargs=numargs@entry=1, args=args@entry=0x7fffffff6b68) at /home/yantar92/Git/emacs/src/lisp.h:2332
#64 0x0000555555757198 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60) at eval.c:3108
#65 0x0000555555755c66 in internal_condition_case_n
(bfun=bfun@entry=0x55555575708c <Ffuncall>, nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60, handlers=handlers@entry=XIL(0x38), hfun=hfun@entry=0x5555555d2ae3 <dsafe_eval_handler>) at eval.c:1707
#66 0x00005555555be7d5 in dsafe__call (inhibit_quit=inhibit_quit@entry=false, f=0x55555575708c <Ffuncall>, nargs=nargs@entry=2, args=args@entry=0x7fffffff6b60) at xdisp.c:3095
#67 0x00005555555be84a in dsafe_call1 (f=<optimized out>, arg=arg@entry=make_fixnum(12548850)) at xdisp.c:3125
#68 0x00005555555d1120 in handle_fontified_prop (it=<optimized out>) at xdisp.c:4644
#69 0x00005555555d4c6e in handle_stop (it=it@entry=0x7fffffff9500) at xdisp.c:4164
#70 0x00005555555e3318 in next_element_from_buffer (it=0x7fffffff9500) at xdisp.c:9752
#71 0x00005555555e1aad in get_next_display_element (it=it@entry=0x7fffffff9500) at xdisp.c:8308
#72 0x00005555555e2a70 in forward_to_next_line_start (it=0x7fffffff9500, skipped_p=skipped_p@entry=0x7fffffff770f, bidi_it_prev=bidi_it_prev@entry=0x0) at xdisp.c:7649
#73 0x00005555555e2f8a in reseat_at_next_visible_line_start (it=it@entry=0x7fffffff9500, on_newline_p=on_newline_p@entry=false) at xdisp.c:7780
#74 0x00005555555e07c4 in move_it_to (it=it@entry=0x7fffffff9500, to_charpos=5143293, to_x=to_x@entry=0, to_y=<optimized out>, to_vpos=to_vpos@entry=-1, op=op@entry=11) at xdisp.c:10964
#75 0x0000555555608676 in redisplay_window (window=XIL(0x7ffe9eccdd4d), just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20258
#76 0x000055555560c4f3 in redisplay_window_0 (window=window@entry=XIL(0x7ffe9eccdd4d)) at xdisp.c:18111
#77 0x0000555555755b5e in internal_condition_case_1
(bfun=bfun@entry=0x55555560c4c0 <redisplay_window_0>, arg=arg@entry=XIL(0x7ffe9eccdd4d), handlers=<optimized out>, hfun=hfun@entry=0x5555555c24fd <redisplay_window_error>) at eval.c:1651
#78 0x00005555555bfeee in redisplay_windows (window=XIL(0x7ffe9eccdd4d)) at xdisp.c:18080
#79 0x00005555555bfe9c in redisplay_windows (window=XIL(0x7ffdf43cbaed)) at xdisp.c:18074
#80 0x00005555555f2be4 in redisplay_internal () at xdisp.c:17497
#81 0x00005555555f3f3e in resize_echo_area_exactly () at xdisp.c:13017
#82 0x00005555556e4c46 in command_loop_1 () at keyboard.c:1584
#83 0x0000555555755ae6 in internal_condition_case (bfun=bfun@entry=0x5555556e4905 <command_loop_1>, handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x5555556d5870 <cmd_error>) at eval.c:1627
#84 0x00005555556d0687 in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at keyboard.c:1174
#85 0x0000555555755a21 in internal_catch (tag=tag@entry=XIL(0x153f0), func=func@entry=0x5555556d0657 <command_loop_2>, arg=arg@entry=XIL(0xa8)) at eval.c:1306
#86 0x00005555556d0634 in command_loop () at keyboard.c:1152
#87 0x00005555556d53e3 in recursive_edit_1 () at keyboard.c:760
#88 0x00005555556d578b in Frecursive_edit () at keyboard.c:843
#89 0x00005555556cf8ab in main (argc=1, argv=0x7fffffffd5d8) at emacs.c:2658
Lisp Backtrace:
"org-fold-core-get-folding-spec" (0xdedff0c0)
"org-activate-folds" (0xffff5e68)
"font-lock-fontify-keywords-region" (0xffff6188)
"font-lock-default-fontify-region" (0xffff6308)
"font-lock-fontify-region" (0xdedff040)
0xf852f918 PVEC_CLOSURE
"jit-lock--run-functions" (0xffff67e8)
"jit-lock-fontify-now" (0xffff69a8)
"jit-lock-function" (0xffff6b68)
"redisplay_internal (C function)" (0x0)
(gdb)
(gdb) q
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.42, cairo version 1.18.2) of 2025-01-12 built on localhost
Repository revision: b82707d70fd5bb78be5766e247e9629eb6553c30
Repository branch: scratch/igc
Windowing system distributor 'The X.Org Foundation', version 11.0.12101014
System Description: Gentoo Linux
Configured using:
'configure --with-mps=yes --with-native-compilation 'CFLAGS=-g3
-I/opt/mps/include -L/opt/mps/lib'
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 WEBP X11 XDBE XIM
XINPUT2 XPM GTK3 ZLIB
--
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#75632; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.