GNU bug report logs - #73181
guix-daemon fails when invoking ‘guix authenticate’ on the Hurd

Previous Next

Package: guix;

Reported by: Ludovic Courtès <ludovic.courtes <at> inria.fr>

Date: Wed, 11 Sep 2024 15:41:02 UTC

Severity: normal

Done: Janneke Nieuwenhuizen <janneke <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 73181 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: <janneke <at> gnu.org>
Cc: 73181 <at> debbugs.gnu.org
Subject: Re: bug#73181: guix-daemon fails when invoking
 ‘guix authenticate’ on the Hurd
Date: Sun, 10 Nov 2024 12:54:33 +0100
Hello,

<janneke <at> 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.

[...]

> 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}

[...]

>   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’.




This bug report was last modified 159 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.