guix-daemon fails when invoking ‘guix authenticate’ on the Hurd

  • Open
  • quality assurance status badge
Details
3 participants
  • janneke
  • Ludovic Courtès
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
normal
L
L
Ludovic Courtès wrote on 11 Sep 17:40 +0200
guix-daemon fails when invoking ‘guix authentic ate’ on the Hurd
(address . bug-guix@gnu.org)
87o74u5hcy.fsf@inria.fr
As reported by yelninei on IRC, Guix on the Hurd is in half-broken state
following the recent ‘core-updates’ merge.

Specifically, sending store items over SSH (and thus breaks offloading
too):

Toggle snippet (5 lines)
$ guix copy --to=localhost:10022 idutils
guix copy: sending 1 store item (1 MiB) to 'localhost'...
guix copy: error: unknown error while sending files over SSH

(Here localhost:10022 is a childhurd.)

Inside the childhurd, we get:

Toggle snippet (4 lines)
root@childhurd ~# tail -1 /var/log/guix-daemon.log
2024-09-09 21:09:03 unexpected build daemon error: stoi

Last time we got that error was in commit
21deb89e287b5821975544118bf137562a91d4e1: guix-daemon was running with
incorrect locale data, and thus ‘std::stoi’ would throw (‘std::stoi’ in
guix-daemon is used for the communication with the ‘guix authenticate’
process, see ‘readAuthenticateReply’).

When running guix-daemon by hand instead of via the Shepherd service,
with the same environment variables, everything works, unless we set one
of the LC_* variables.

Ludo’.
L
L
Ludovic Courtès wrote on 11 Sep 19:08 +0200
Re: bug#73181: guix-daemon fails when invoking ‘guix authenticate’ on the Hurd
(address . 73181@debbugs.gnu.org)
87a5ge5d94.fsf@gnu.org
Ludovic Courtès <ludovic.courtes@inria.fr> skribis:

Toggle quote (11 lines)
> Inside the childhurd, we get:
>
> root@childhurd ~# tail -1 /var/log/guix-daemon.log
> 2024-09-09 21:09:03 unexpected build daemon error: stoi
>
> Last time we got that error was in commit
> 21deb89e287b5821975544118bf137562a91d4e1: guix-daemon was running with
> incorrect locale data, and thus ‘std::stoi’ would throw (‘std::stoi’ in
> guix-daemon is used for the communication with the ‘guix authenticate’
> process, see ‘readAuthenticateReply’).

I wanted to ‘rpctrace’ to see what ‘guix authenticate’ and ‘guix-daemon’
are telling each other. The problem is that ‘rpctrace’ is kinda broken,
or at least it wrecks havoc when trying to follow forks or something.

But I found a trick that allowed me to trace just ‘guix authenticate’:

Toggle snippet (9 lines)
root@childhurd ~# cat intercept-guix.sh
#!/bin/sh
/usr/bin/env > /tmp/env.log
echo >> /tmp/env.log
echo "$@" >> /tmp/env.log
exec rpctrace -o /tmp/rpctrace.log -s 200 /gnu/store/cg64w7mv1v2r188rzcgksdva9cvj8vir-guix-1.4.0-24.9a2ddcc/bin/guix "$@"
root@childhurd ~# LC_ALL=fr_FR.utf8 GUIX=$PWD/intercept-guix.sh /gnu/store/cg64w7mv1v2r188rzcgksdva9cvj8vir-guix-1.4.0-24.9a2ddcc/bin/guix-daemon --build-users-group guixbuild --max-silent-time 3600 --timeout 86400 --log-compression gzip --discover=no --disable-chroot --disable-deduplication

(Here “LC_ALL=fr_FR.utf8” allows me to reproduce the stoi bug.)

We get this:

Toggle snippet (13 lines)
root@childhurd ~# tail /tmp/rpctrace.log
5<--35(pid166)->dir_lookup ("gnu/store/9ghq6s4mq5sff9cwqrmn26ivycn3p8ql-guile-3.0.9/lib/guile/3.0/ccache/system/foreign-library.go" 4194305 0) = 0 1 "" 67<--70(pid166)
67<--70(pid166)->io_seek_request (0 2) = 0 98141
67<--70(pid166)->io_map_request () = 0 69<--66(pid166) (null)
task30(pid166)-> 2089 (0 98141 0 1 69<--66(pid166) 0 1 1 7 1) = 0 61452288
task30(pid166)-> 3206 (pn{ 28}) = 0
task30(pid166)-> 3206 (pn{ 27}) = 0
task30(pid166)-> 2024 (61517824 18824 0 3) = 0
14<--31(pid166)->io_write_request ("GC Warning: Repeated allocation of very large block (appr. size 112 KiB):\n\tMay lead to memory leak and poor performance\n" -1) = 0 120
task30(pid166)-> 2012 (1 22) = 0 {0 25 195772416 15151104 0 0 0 0 1726072790 570000 0 0 0 0 0 0 0 0 1726072790 0 570000000 0}
task30(pid166)-> 2012 (3 12) = 0 {0 30000 0 20000 0 0 30000000 0 0 0 20000000 0}

That warning comes from libgc and there’s no such warning when LC_ALL is
left unset, which is why it works in that case.

The warning goes to stderr, but that’s what guix-daemon ends up reading,
hence the ‘stoi’ error. One can reproduce that by printing something on
(current-error-port) from ‘guix authenticate’ and running, say, “make
check TESTS=tests/store.scm”: a bunch of tests fail.

It’s not clear to me why libgc keeps printing that warning on i586-gnu
(I think it’s fine on i686-linux so there might be a portability issue),
and it’s not clear either why changing the locale triggers the warning
(it might have to do with the so-called GC “black lists”, since loading
a locale effectively changes the address space layout somewhat).

I see several possible things to do:

1. Disable GC warnings altogether in Guix by setting ‘GC_warn_proc’.

2. Make sure guix-daemon discards stderr from agents such as ‘guix
authenticate’.

3. Figure out why those “Repeated allocation” messages are so frequent
on i586-gnu and Do Something About It™.

Thoughts?

Ludo’.
J
J
janneke wrote on 31 Oct 20:14 +0100
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 73181@debbugs.gnu.org)
87h68snkzk.fsf@gnu.org
Ludovic Courtès writes:

Hi!

Toggle quote (13 lines)
> Ludovic Courtès <ludovic.courtes@inria.fr> skribis:
>
>> Inside the childhurd, we get:
>>
>> root@childhurd ~# tail -1 /var/log/guix-daemon.log
>> 2024-09-09 21:09:03 unexpected build daemon error: stoi
>>
>> Last time we got that error was in commit
>> 21deb89e287b5821975544118bf137562a91d4e1: guix-daemon was running with
>> incorrect locale data, and thus ‘std::stoi’ would throw (‘std::stoi’ in
>> guix-daemon is used for the communication with the ‘guix authenticate’
>> process, see ‘readAuthenticateReply’).

[snip some great debugging, phew!]

Toggle quote (3 lines)
> That warning comes from libgc and there’s no such warning when LC_ALL is
> left unset, which is why it works in that case.

How about

0. Unsetting LC_ALL on the Hurd

would that work?

Toggle quote (12 lines)
> I see several possible things to do:
>
> 1. Disable GC warnings altogether in Guix by setting ‘GC_warn_proc’.
>
> 2. Make sure guix-daemon discards stderr from agents such as ‘guix
> authenticate’.
>
> 3. Figure out why those “Repeated allocation” messages are so frequent
> on i586-gnu and Do Something About It™.
>
> Thoughts?

If 0., which seems easiest, does not work then Obviously(?) 3. is nicer
but (much?) harder than 2., which is nicer than 1. However, 1. is much
nicer than our current situation of not having offloading to our
childhurds and not having up-to-date substitutes. How about doing
1. right now but only for the Hurd, until we get 2. or 3.?

Greeting,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 4 Nov 09:21 +0100
(address . janneke@gnu.org)(address . 73181@debbugs.gnu.org)
874j4n5s02.fsf@inria.fr
Hello,

<janneke@gnu.org> skribis:

Toggle quote (2 lines)
> Ludovic Courtès writes:

[...]

Toggle quote (9 lines)
>> That warning comes from libgc and there’s no such warning when LC_ALL is
>> left unset, which is why it works in that case.
>
> How about
>
> 0. Unsetting LC_ALL on the Hurd
>
> would that work?

I’m not sure, but if it does, it’s only “by chance”.

Toggle quote (18 lines)
>> I see several possible things to do:
>>
>> 1. Disable GC warnings altogether in Guix by setting ‘GC_warn_proc’.
>>
>> 2. Make sure guix-daemon discards stderr from agents such as ‘guix
>> authenticate’.
>>
>> 3. Figure out why those “Repeated allocation” messages are so frequent
>> on i586-gnu and Do Something About It™.
>>
>> Thoughts?
>
> If 0., which seems easiest, does not work then Obviously(?) 3. is nicer
> but (much?) harder than 2., which is nicer than 1. However, 1. is much
> nicer than our current situation of not having offloading to our
> childhurds and not having up-to-date substitutes. How about doing
> 1. right now but only for the Hurd, until we get 2. or 3.?

Yeah, let’s start with (1), maybe with the patch below (untested)?

(2) and (3) would be nice, but it goes with increasing difficulty.

Ludo’.
Toggle diff (20 lines)
diff --git a/gnu/packages/aux-files/guile-launcher.c b/gnu/packages/aux-files/guile-launcher.c
index ad0094bff5..6a59905a28 100644
--- a/gnu/packages/aux-files/guile-launcher.c
+++ b/gnu/packages/aux-files/guile-launcher.c
@@ -73,6 +73,15 @@ main (int argc, char **argv)
which is always preferable over the C locale. */
setlocale (LC_ALL, "en_US.utf8");
+#if defined __GNU__
+ /* XXX: On 32-bit GNU/Hurd (i586-gnu), libgc emits "Repeated allocation"
+ warnings that are annoying and interfere with communications between
+ 'guix-daemon' and 'guix authenticate':
+ <https://issues.guix.gnu.org/73181>. Silence them. */
+ static void no_warnings (char *message, GC_word arg) { };
+ GC_set_warn_proc (no_warnings);
+#endif
+
const char *str;
str = getenv ("GUILE_LOAD_PATH");
load_path = str != NULL ? strdup (str) : NULL;
J
J
janneke wrote on 5 Nov 12:26 +0100
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 73181@debbugs.gnu.org)
87ed3phqfm.fsf@gnu.org
Ludovic Courtès writes:

Hello,

Toggle quote (4 lines)
> <janneke@gnu.org> skribis:
>
>> Ludovic Courtès writes:

[..]

Toggle quote (10 lines)
>>> I see several possible things to do:
>>>
>>> 1. Disable GC warnings altogether in Guix by setting ‘GC_warn_proc’.
>>>
>>> 2. Make sure guix-daemon discards stderr from agents such as ‘guix
>>> authenticate’.
>>>
>>> 3. Figure out why those “Repeated allocation” messages are so frequent
>>> on i586-gnu and Do Something About It™.

[..]

Toggle quote (4 lines)
> Yeah, let’s start with (1), maybe with the patch below (untested)?
>
> (2) and (3) would be nice, but it goes with increasing difficulty.

So...find two patches attached. A tested version of (untested) which
was very helpful but did not compile. I should have tested with #if 1,
and use #:tests? #f with guix right away... ;)

Anyway, using this patch 0001 it seems that suppressing the warnings
works, I no longer get

Toggle snippet (3 lines)
"GC Warning: Repeated allocation of very large block (appr. size 112 KiB):\n\tMay lead to memory leak and poor performance\n"

but still get

Toggle snippet (3 lines)
unexpected build daemon error: stoi

and the copy (and offload) still fails. Then I tried resetting LC_ALL

Toggle quote (8 lines)
>> How about
>>
>> 0. Unsetting LC_ALL on the Hurd
>>
>> would that work?
>
> I’m not sure, but if it does, it’s only “by chance”.

(option 0.) anyway in a followup patch. Adding this patch 0003 (patch
0002 was just the guix package update), also the "stoi" warning is gone,
and offloading works.

So it seems that we have a workaround that "works by chance", WDYT?

Greetings,
Janneke
From 3d399e51104171ad328bea66ebdc1d6b0ac99685 Mon Sep 17 00:00:00 2001
Message-ID: <3d399e51104171ad328bea66ebdc1d6b0ac99685.1730803153.git.janneke@gnu.org>
From: Janneke Nieuwenhuizen <janneke@gnu.org>
Date: Mon, 4 Nov 2024 14:54:55 +0100
Subject: [PATCH 1/3] guile: Silence GC warnings on the Hurd.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

This should work around https://issues.guix.gnu.org/73181, resurrecting
offloading to the Hurd.

* gnu/packages/aux-files/guile-launcher.c (no_warnings)[__GNU__]: New
function.
(main)[__GNU__]: Use it to silence libgc warnings.

Co-authored-by: Ludovic Courtès <ludo@gnu.org>.
Change-Id: I8f30732d192ce46144da4a1a081813a104a5f376
---
gnu/packages/aux-files/guile-launcher.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)

Toggle diff (49 lines)
diff --git a/gnu/packages/aux-files/guile-launcher.c b/gnu/packages/aux-files/guile-launcher.c
index ad0094bff5..bc7fa21b63 100644
--- a/gnu/packages/aux-files/guile-launcher.c
+++ b/gnu/packages/aux-files/guile-launcher.c
@@ -1,7 +1,8 @@
/* GNU Guix --- Functional package management for GNU
Copyright 1996-1997,2000-2001,2006,2008,2011,2013,2018,2020,2021
Free Software Foundation, Inc.
- Copyright (C) 2020 Ludovic Courtès <ludo@gnu.org>
+ Copyright (C) 2020, 2024 Ludovic Courtès <ludo@gnu.org>
+ Copyright (C) 2024 Janneke Nieuwenhuizen <janneke@gnu.org>
This file is part of GNU Guix.
@@ -28,6 +29,14 @@
#include <locale.h>
#include <libguile.h>
+#if defined __GNU__
+#include <gc.h>
+static void
+no_warnings (char *message, GC_word arg)
+{
+}
+#endif
+
/* Saved values of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH. */
static const char *load_path, *load_compiled_path;
@@ -73,6 +82,14 @@ main (int argc, char **argv)
which is always preferable over the C locale. */
setlocale (LC_ALL, "en_US.utf8");
+#if defined __GNU__
+ /* XXX: On 32-bit GNU/Hurd (i586-gnu), libgc emits "Repeated allocation"
+ warnings that are annoying and interfere with communications between
+ 'guix-daemon' and 'guix authenticate':
+ <https://issues.guix.gnu.org/73181>. Silence them. */
+ GC_set_warn_proc (no_warnings);
+#endif
+
const char *str;
str = getenv ("GUILE_LOAD_PATH");
load_path = str != NULL ? strdup (str) : NULL;

base-commit: 20c7b8dd04e421a139a02438cf1ddfdfe544a446
--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
From b62d59cf5cc9f968bedd8126f587bc8e14f7964c Mon Sep 17 00:00:00 2001
Message-ID: <b62d59cf5cc9f968bedd8126f587bc8e14f7964c.1730803153.git.janneke@gnu.org>
In-Reply-To: <3d399e51104171ad328bea66ebdc1d6b0ac99685.1730803153.git.janneke@gnu.org>
References: <3d399e51104171ad328bea66ebdc1d6b0ac99685.1730803153.git.janneke@gnu.org>
From: Janneke Nieuwenhuizen <janneke@gnu.org>
Date: Mon, 4 Nov 2024 17:38:46 +0100
Subject: [PATCH 3/3] squash! guile: Silence GC warnings on the Hurd.
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

Change-Id: Ia720221ed285d3e56938cfa37989d2c7c07b00e3
---
gnu/packages/aux-files/guile-launcher.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)

Toggle diff (37 lines)
diff --git a/gnu/packages/aux-files/guile-launcher.c b/gnu/packages/aux-files/guile-launcher.c
index bc7fa21b63..ee6da76cc4 100644
--- a/gnu/packages/aux-files/guile-launcher.c
+++ b/gnu/packages/aux-files/guile-launcher.c
@@ -75,19 +75,22 @@ inner_main (void *unused, int argc, char **argv)
int
main (int argc, char **argv)
{
- /* Try to install the current locale; remain silent if it fails. */
- if (setlocale (LC_ALL, "") == NULL)
- /* The 'guix pull'-provided 'guix' includes at least en_US.utf8 so use
- that. That gives us UTF-8 support for 'scm_to_locale_string', etc.,
- which is always preferable over the C locale. */
- setlocale (LC_ALL, "en_US.utf8");
-
#if defined __GNU__
+ /* Try to install the C locale; remain silent if it fails. */
+ setlocale (LC_ALL, "C");
+
/* XXX: On 32-bit GNU/Hurd (i586-gnu), libgc emits "Repeated allocation"
warnings that are annoying and interfere with communications between
'guix-daemon' and 'guix authenticate':
<https://issues.guix.gnu.org/73181>. Silence them. */
GC_set_warn_proc (no_warnings);
+#else
+ /* Try to install the current locale; remain silent if it fails. */
+ if (setlocale (LC_ALL, "") == NULL)
+ /* The 'guix pull'-provided 'guix' includes at least en_US.utf8 so use
+ that. That gives us UTF-8 support for 'scm_to_locale_string', etc.,
+ which is always preferable over the C locale. */
+ setlocale (LC_ALL, "en_US.utf8");
#endif
const char *str;
--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 5 Nov 15:03 +0100
(address . janneke@gnu.org)(address . 73181@debbugs.gnu.org)
877c9hzsjy.fsf@inria.fr
Hello!

<janneke@gnu.org> skribis:

Toggle quote (10 lines)
> Anyway, using this patch 0001 it seems that suppressing the warnings
> works, I no longer get
>
> "GC Warning: Repeated allocation of very large block (appr. size 112 KiB):\n\tMay lead to memory leak and poor performance\n"
>
>
> but still get
>
> unexpected build daemon error: stoi

Damnit. Could you check with rpctrace what the daemon receives?

I wonder if I misunderstood what the root cause is.

Toggle quote (21 lines)
> From 3d399e51104171ad328bea66ebdc1d6b0ac99685 Mon Sep 17 00:00:00 2001
> Message-ID: <3d399e51104171ad328bea66ebdc1d6b0ac99685.1730803153.git.janneke@gnu.org>
> From: Janneke Nieuwenhuizen <janneke@gnu.org>
> Date: Mon, 4 Nov 2024 14:54:55 +0100
> Subject: [PATCH 1/3] guile: Silence GC warnings on the Hurd.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Content-Transfer-Encoding: 8bit
> Content-Type: text/plain; charset=UTF-8
>
> This should work around <https://issues.guix.gnu.org/73181>, resurrecting
> offloading to the Hurd.
>
> * gnu/packages/aux-files/guile-launcher.c (no_warnings)[__GNU__]: New
> function.
> (main)[__GNU__]: Use it to silence libgc warnings.
>
> Co-authored-by: Ludovic Courtès <ludo@gnu.org>.
> Change-Id: I8f30732d192ce46144da4a1a081813a104a5f376

LGTM.

Toggle quote (4 lines)
> #if defined __GNU__
> + /* Try to install the C locale; remain silent if it fails. */
> + setlocale (LC_ALL, "C");

This I’d rather avoid, unless we have a good understanding of why this
would help.

Thanks for working on it!

Ludo’.
J
J
janneke wrote on 5 Nov 16:41 +0100
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 73181@debbugs.gnu.org)
871pzphemc.fsf@gnu.org
Ludovic Courtès writes:

Hi!

Toggle quote (17 lines)
> <janneke@gnu.org> skribis:
>
>> Anyway, using this patch 0001 it seems that suppressing the warnings
>> works, I no longer get
>>
>> "GC Warning: Repeated allocation of very large block (appr. size 112
>> KiB):\n\tMay lead to memory leak and poor performance\n"
>>
>>
>> but still get
>>
>> unexpected build daemon error: stoi
>
> Damnit. Could you check with rpctrace what the daemon receives?
>
> I wonder if I misunderstood what the root cause is.

Yes :-( I captured a `guix offload test' run, see attached.

Toggle quote (14 lines)
>> From 3d399e51104171ad328bea66ebdc1d6b0ac99685 Mon Sep 17 00:00:00 2001
>> Message-ID: <3d399e51104171ad328bea66ebdc1d6b0ac99685.1730803153.git.janneke@gnu.org>
>> From: Janneke Nieuwenhuizen <janneke@gnu.org>
>> Date: Mon, 4 Nov 2024 14:54:55 +0100
>> Subject: [PATCH 1/3] guile: Silence GC warnings on the Hurd.
>> * gnu/packages/aux-files/guile-launcher.c (no_warnings)[__GNU__]: New
>> function.
>> (main)[__GNU__]: Use it to silence libgc warnings.
>>
>> Co-authored-by: Ludovic Courtès <ludo@gnu.org>.
>> Change-Id: I8f30732d192ce46144da4a1a081813a104a5f376
>
> LGTM.

Do we want to push this...as it doesn't really

Toggle quote (3 lines)
>> This should work around https://issues.guix.gnu.org/73181, resurrecting
>> offloading to the Hurd.

just yet.

Toggle quote (7 lines)
>> #if defined __GNU__
>> + /* Try to install the C locale; remain silent if it fails. */
>> + setlocale (LC_ALL, "C");
>
> This I’d rather avoid, unless we have a good understanding of why this
> would help.

Yes, that was clear to me; just wanted to have this data point :)

Toggle quote (2 lines)
> Thanks for working on it!

Yeat it's not much work, it just takes such a long wait each time.

Greetings,
Janneke
--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
L
L
Ludovic Courtès wrote on 10 Nov 12:54 +0100
(address . janneke@gnu.org)(address . 73181@debbugs.gnu.org)
875xovwbgm.fsf@gnu.org
Hello,

<janneke@gnu.org> skribis:

Toggle quote (17 lines)
>>> Anyway, using this patch 0001 it seems that suppressing the warnings
>>> works, I no longer get
>>>
>>> "GC Warning: Repeated allocation of very large block (appr. size 112
>>> KiB):\n\tMay lead to memory leak and poor performance\n"
>>>
>>>
>>> but still get
>>>
>>> unexpected build daemon error: stoi
>>
>> Damnit. Could you check with rpctrace what the daemon receives?
>>
>> I wonder if I misunderstood what the root cause is.
>
> Yes :-( I captured a `guix offload test' run, see attached.

[...]

Toggle quote (3 lines)
> task31(pid198)-> 2058 (4) = 0 22<--9(pid198)
> 22<--9(pid198)->exec_startup_get_info () = 0 134517280 134512692 352 237568 16777216 0 "/gnu/store/7wgwfsbvq8m9zkz03d27ij53jciliz9n-guix-1.4.0-27.3d399e5/libexec/guix/guile\0\\0/run/current-system/profile/bin/guix\0authenticate\0" "SHELL=/gnu/store/dm5shwb20i38wqdkmyqvhqfi0hmq1lr1-bash-5.1.16/bin/bash\0XDG_CONFIG_DIRS=/root/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg\0PKG_CONFIG_PATH=/run/current-system/profile/lib/p" { 16<--25(pid198) 13<--27(pid198) 13<--27(pid198) 4<--32(pid198) 12<--33(pid198)} { 11<--34(pid198) 6<--35(pid198) 2<--36(pid198) 26<--38(pid198) (null) (null)} {18 0 0 0 0}

[...]

Toggle quote (13 lines)
> 26<--38(pid198)->proc_setmsgport_request ( 44<--48(pid-1)) = 0 (null)
> 26<--38(pid198)->proc_set_arg_locations_request (17014228 17014248) = 0
> task31(pid198)-> 3204 (1) = 0 pn{ 19}
> task31(pid198)-> 3215 (pn{ 19} 49) = 0
> task31(pid198)-> 3204 (1) = 0 pn{ 20}
> task31(pid198)-> 3210 (pn{ 20} 1) = 0
> 26<--38(pid198)->proc_handle_exceptions_request ( 49<--51(pid-1) 50<--52(pid-1) 5 {75 31 31 31 0 0 0 0 0 0 0 0 19291280 23 0 21548192 0}) = 0
> thread46(pid198)-> 2068 (3 51) = 0
> task31(pid198)-> 3206 (pn{ 19}) = 0
> task31(pid198)-> 2023 (17031168 20) = 0
> task31(pid198)-> 2023 (17027072 24) = 0
> 6<--35(pid198)->dir_lookup ("gnu/store/81ffz0prarfczr408ydnps31jf72s5ly-glibc-cross-i586-pc-gnu-2.39/share/locale/locale.alias" 4194305 0) = 0 1 "" 51<--47(pid198)

Does that ‘locale.alias’ file exists?

Did you try several LC_ALL=xxx values to see which one would work and
which one wouldn’t?

So after all, there may be two issues: the “Repeated allocation” thing,
and a locale issue.

Thanks,
Ludo’.
J
J
janneke wrote on 10 Nov 13:01 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 73181@debbugs.gnu.org)
87iksv1en9.fsf@gnu.org
Ludovic Courtès writes:

Hi,

Toggle quote (26 lines)
> <janneke@gnu.org> skribis:
>
>>>> Anyway, using this patch 0001 it seems that suppressing the warnings
>>>> works, I no longer get
>>>>
>>>> "GC Warning: Repeated allocation of very large block (appr. size 112
>>>> KiB):\n\tMay lead to memory leak and poor performance\n"
>>>>
>>>>
>>>> but still get
>>>>
>>>> unexpected build daemon error: stoi
>>>
>>> Damnit. Could you check with rpctrace what the daemon receives?
>>>
>>> I wonder if I misunderstood what the root cause is.
>>
>> Yes :-( I captured a `guix offload test' run, see attached.
>
> [...]
>
>> ("gnu/store/81ffz0prarfczr408ydnps31jf72s5ly-glibc-cross-i586-pc-gnu-2.39/share/locale/locale.alias"
>> 4194305 0) = 0 1 "" 51<--47(pid198)
>
> Does that ‘locale.alias’ file exists?

Yes

Toggle snippet (13 lines)
root@childhurd ~# tail /gnu/store/81ffz0prarfczr408ydnps31jf72s5ly-glibc-cross-i586-pc-gnu-2.39/share/locale/locale.alias
portuguese pt_PT.ISO-8859-1
romanian ro_RO.ISO-8859-2
russian ru_RU.ISO-8859-5
slovak sk_SK.ISO-8859-2
slovene sl_SI.ISO-8859-2
slovenian sl_SI.ISO-8859-2
spanish es_ES.ISO-8859-1
swedish sv_SE.ISO-8859-1
thai th_TH.TIS-620
turkish tr_TR.ISO-8859-9

Toggle quote (3 lines)
> Did you try several LC_ALL=xxx values to see which one would work and
> which one wouldn’t?

I tried fr_FR.UTF-8 and nl_NL.UTF-8, both fail. And then LC_ALL=C,
which works. Any other ideas?

Toggle quote (3 lines)
> So after all, there may be two issues: the “Repeated allocation” thing,
> and a locale issue.

Yes, it looks like the we can suppress the warnings though, which
hides the "Repeated allocation" issue...

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 73181@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 73181
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch