Chunked store references in compiled code break grafting (again)

  • Done
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Mathieu Lirzin
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Mathieu Lirzin
Severity
serious
Merged with
M
M
Mathieu Lirzin wrote on 8 Feb 2018 18:20
‘gcc’ doesn't compile with LD_LIBRARY_PATH="$HOME/.guix-profile/lib"
(address . bug-guix@gnu.org)
87vaf72y9w.fsf@gnu.org
Hello,

I have been facing a weird issue where some shitty build tool I was
using has tried to run ‘cmake’ after setting LD_LIBRARY_PATH. The
result was a non terminating call to ‘collect2’.

Here is a way to reproduce the issue:

$ guix environment --pure --ad-hoc gcc-toolchain
$ echo "int main() { return 0; }" > foo.c
$ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc foo.c

When adding ‘binutils’ to the environment, the problem dissapears since
‘ld-wrapper’ is not used anymore.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 16 Feb 2018 11:14
(name . Mathieu Lirzin)(address . mthl@gnu.org)(address . 30395@debbugs.gnu.org)
87k1vdqm09.fsf@gnu.org
Hi Mathieu,

Mathieu Lirzin <mthl@gnu.org> skribis:

Toggle quote (10 lines)
> I have been facing a weird issue where some shitty build tool I was
> using has tried to run ‘cmake’ after setting LD_LIBRARY_PATH. The
> result was a non terminating call to ‘collect2’.
>
> Here is a way to reproduce the issue:
>
> $ guix environment --pure --ad-hoc gcc-toolchain
> $ echo "int main() { return 0; }" > foo.c
> $ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc foo.c

That works for me (i.e., ‘gcc’ runs to completion just fine.)

But I suppose this depends on what’s in ~/.guix-profile/lib. If you
have a conflicting GCC version there (which is not the case for me), it
could break.

Could you run the snippet you provided above with ‘--verbose’ passed to
‘gcc’? That will allow us to see what libraries and tools it picks up.

Toggle quote (3 lines)
> When adding ‘binutils’ to the environment, the problem dissapears since
> ‘ld-wrapper’ is not used anymore.

What makes you think ‘ld-wrapper’ is involved?

Anyway, the ‘--verbose’ output should give us more insight.

Thanks,
Ludo’.
M
M
Mathieu Lirzin wrote on 16 Feb 2018 13:01
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30395@debbugs.gnu.org)
87mv09gn3i.fsf@gnu.org
Hi Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (18 lines)
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> I have been facing a weird issue where some shitty build tool I was
>> using has tried to run ‘cmake’ after setting LD_LIBRARY_PATH. The
>> result was a non terminating call to ‘collect2’.
>>
>> Here is a way to reproduce the issue:
>>
>> $ guix environment --pure --ad-hoc gcc-toolchain
>> $ echo "int main() { return 0; }" > foo.c
>> $ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc foo.c
>
> That works for me (i.e., ‘gcc’ runs to completion just fine.)
>
> But I suppose this depends on what’s in ~/.guix-profile/lib. If you
> have a conflicting GCC version there (which is not the case for me), it
> could break.

Interesting. :-)

Toggle quote (3 lines)
> Could you run the snippet you provided above with ‘--verbose’ passed to
> ‘gcc’? That will allow us to see what libraries and tools it picks up.

Here it is

Toggle snippet (37 lines)
mthl@godel ~ [env]$ LD_LIBRARY_PATH="$HOME/.guix-profile/lib" gcc --verbose foo.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
gcc version 7.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/cc1 -quiet -v foo.c -quiet -dumpbase foo.c -mtune=generic -march=x86-64 -auxbase foo -version -o /tmp/ccU8U3nt.s
GNU C11 (GCC) version 7.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/no-gcc-local-prefix/include"
ignoring nonexistent directory "/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../../../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/include
/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include
/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/include-fixed
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/include
End of search list.
GNU C11 (GCC) version 7.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 54a938749d3b2f496e537dee0d578856
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
as -v --64 -o /tmp/ccRLpf89.o /tmp/ccU8U3nt.s
GNU assembler version 2.28.1 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.28.1
COMPILER_PATH=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/:/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../../:/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/collect2 -plugin /gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/liblto_plugin.so -plugin-opt=/gnu/store/xjpchnxm9fgg05fqm9apyhqlqd5q5js8-gcc-7.3.0/libexec/gcc/x86_64-unknown-linux-gnu/7.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccKVXTVQ.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/ld-linux-x86-64.so.2 /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crt1.o /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crti.o /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/crtbegin.o -L/gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib -L/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0 -L/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/../../.. -L/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib /tmp/ccRLpf89.o -lgcc --as-needed -lgcc_s --no-as-needed -L/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib -rpath=/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib -rpath=/gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib -lgcc_s -lc -lgcc --as-needed -lgcc_s --no-as-needed /gnu/store/45rhjm5ryms10frcyrzcdp9yk4al4lnq-gcc-7.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/7.3.0/crtend.o /gnu/store/9nxcfpfyrcz3aifwg55nls92sa3rhzs2-profile/lib/crtn.o

Toggle quote (5 lines)
>> When adding ‘binutils’ to the environment, the problem dissapears since
>> ‘ld-wrapper’ is not used anymore.
>
> What makes you think ‘ld-wrapper’ is involved?

GCC is waiting on ‘collect2’ to finish and ‘collect2’ according to [1]
tries to find ‘ld’. When ‘ld’ is provided by Binutils the program
completes but not with ‘ld-wrapper’ on my machine, so I suspect this is
related to ‘ld-wrapper’, but maybe this is just a symptom of something
else.

Thanks.


--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 16 Feb 2018 14:03
(name . Mathieu Lirzin)(address . mthl@gnu.org)(address . 30395@debbugs.gnu.org)
874lmhozml.fsf@gnu.org
Mathieu Lirzin <mthl@gnu.org> skribis:

Toggle quote (6 lines)
> GCC is waiting on ‘collect2’ to finish and ‘collect2’ according to [1]
> tries to find ‘ld’. When ‘ld’ is provided by Binutils the program
> completes but not with ‘ld-wrapper’ on my machine, so I suspect this is
> related to ‘ld-wrapper’, but maybe this is just a symptom of something
> else.

Oooh, I see. It could be the ‘guile’ used by ld-wrapper that fails
somehow.

Do you have ‘guile’ in ~/.guix-profile? You could run again that gcc
command, this time prefixed with “strace -f -o log” to see which
libguile.so is being used when ‘ld’ is invoked, and whether something
else is going on, such as auto-compilation or something?

Ludo’.
M
M
Mathieu Lirzin wrote on 16 Feb 2018 15:56
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30395@debbugs.gnu.org)
871shlkmp6.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (16 lines)
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> GCC is waiting on ‘collect2’ to finish and ‘collect2’ according to [1]
>> tries to find ‘ld’. When ‘ld’ is provided by Binutils the program
>> completes but not with ‘ld-wrapper’ on my machine, so I suspect this is
>> related to ‘ld-wrapper’, but maybe this is just a symptom of something
>> else.
>
> Oooh, I see. It could be the ‘guile’ used by ld-wrapper that fails
> somehow.
>
> Do you have ‘guile’ in ~/.guix-profile? You could run again that gcc
> command, this time prefixed with “strace -f -o log” to see which
> libguile.so is being used when ‘ld’ is invoked, and whether something
> else is going on, such as auto-compilation or something?

I don't have ‘guile’ in my profile, but I have ‘glibc@2.25’.

After looking at the attached ‘strace’ log, as you initially guessed
this issue is that multiple GCC are loaded. My ‘gcc-toolchain’ is using
GCC 7.3 and ‘glibc’ is referring to GCC 5.4.

After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
don't need to install ‘binutils’ in my profile anymore. I must admit
that I still don't understand the details, but do you see a way to
prevent such silent misconfiguration?

Thanks for your time.
Attachment: log
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 16 Feb 2018 17:43
(name . Mathieu Lirzin)(address . mthl@gnu.org)(address . 30395@debbugs.gnu.org)
87h8qgnavo.fsf@gnu.org
Mathieu Lirzin <mthl@gnu.org> skribis:

Toggle quote (4 lines)
> After looking at the attached ‘strace’ log, as you initially guessed
> this issue is that multiple GCC are loaded. My ‘gcc-toolchain’ is using
> GCC 7.3 and ‘glibc’ is referring to GCC 5.4.

Normally ‘glibc’ does not contain references to ‘gcc’:

Toggle snippet (7 lines)
$ guix size /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
store item total self
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25 38.5 37.1 96.3%
/gnu/store/zhrajv6qf2hzn9c3g2bb07559hyrz5xp-bash-static-4.4.12 1.4 1.4 3.7%
total: 38.5 MiB

Toggle quote (3 lines)
> After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
> don't need to install ‘binutils’ in my profile anymore.

I don’t get it yet. The log shows this:

Toggle snippet (15 lines)
9543 execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0

9543 open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

9543 write(2, "Uncaught exception:\n", 20) = 20
9543 futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
9543 futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
9543 close(3) = 0
9543 close(4) = 0
9543 munmap(0x7f5d455e8000, 4096) = 0
9543 exit(0) = ?
9539 <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
9539 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---

This is the execution of ld-wrapper and it terminates with “Uncaught
exception”, which isn’t really helpful. Apparently this happens before
‘boot-9.scm’ was even search for.

Can you reproduce it by running ‘ld’ directly in that environment? Or
better yet, by running ‘guile’? The next thing is to try and do that in
gdb…

Ludo’.
M
M
Mathieu Lirzin wrote on 17 Feb 2018 20:02
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30395@debbugs.gnu.org)
87a7w7a18h.fsf@gnu.org
Hello,

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (14 lines)
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> After looking at the attached ‘strace’ log, as you initially guessed
>> this issue is that multiple GCC are loaded. My ‘gcc-toolchain’ is using
>> GCC 7.3 and ‘glibc’ is referring to GCC 5.4.
>
> Normally ‘glibc’ does not contain references to ‘gcc’:
>
> $ guix size /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
> store item total self
> /gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25 38.5 37.1 96.3%
> /gnu/store/zhrajv6qf2hzn9c3g2bb07559hyrz5xp-bash-static-4.4.12 1.4 1.4 3.7%
> total: 38.5 MiB

OK, My guess regarding the link between glibc@2.25 and gcc@5.4 was
solely based on the proximity in the order of ‘.so’ files opening.

Toggle snippet (12 lines)
1382 open("/home/mthl/.guix-profile/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/3v8z40rdvpbdpaccfqgvxkw1dnipc321-gmp-6.1.2/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/x86_64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/x86_64", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/tls", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/x86_64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1382 stat("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/x86_64", 0x7ffec8dd5730) = -1 ENOENT (No such file or directory)
1382 open("/gnu/store/6wyjls0q2c9gjskkplsr1ad09p3d8gzg-gcc-5.4.0-lib/lib/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3

Even if it was effective in term of solving my specific issue, it was
really not a rigorous analysis.

Toggle quote (27 lines)
>> After removing ‘glibc’ and from my profile calling ‘gcc’ completes, so I
>> don't need to install ‘binutils’ in my profile anymore.
>
> I don’t get it yet. The log shows this:
>
> 9543 execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0
>
> 9543 open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>
> 9543 write(2, "Uncaught exception:\n", 20) = 20
> 9543 futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> 9543 futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> 9543 close(3) = 0
> 9543 close(4) = 0
> 9543 munmap(0x7f5d455e8000, 4096) = 0
> 9543 exit(0) = ?
> 9539 <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
> 9539 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
>
> This is the execution of ld-wrapper and it terminates with “Uncaught
> exception”, which isn’t really helpful. Apparently this happens before
> ‘boot-9.scm’ was even search for.
>
> Can you reproduce it by running ‘ld’ directly in that environment? Or
> better yet, by running ‘guile’? The next thing is to try and do that
> in gdb…

Yes I can reproduce simply by running ‘guile’ (v2.2.2 and v2.2.3). :-)

Toggle snippet (6 lines)
LD_LIBRARY_PATH="$HOME/.guix-profile/lib" guile
Uncaught exception:
Throw to key encoding-error with args ("scm_to_stringn" "cannot convert
narrow string to output locale" 22 #f #f)

I have tried to set LC_ALL=C, but this doesn't have any impact. Here
are the outputs of ‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f
-s 1000 -o OUTPUT guile’ for the failing environment with glibc@2.25 in
the profile:
Attachment: bad-guile-log
and when glibc is removed from the profile:
Attachment: good-guile-log
I have tried to first debug ‘guile’ with ‘gdb’. Since it crashes, I
don't know to get any backtrace from it. However I have noticed that
since ‘gdb’ itself is linked with libguile and suffers from the same
problem with LD_LIBRARY_PATH improperly set, but doesn't crash. So I
have run the following:

Toggle snippet (70 lines)
mthl@godel ~/src/guile$ gdb gdb
[...]
Reading symbols from gdb...(no debugging symbols found)...done.
(gdb) set environment LD_LIBRARY_PATH /home/mthl/.guix-profile/lib
(gdb) run
Starting program: /gnu/store/ly635xcgaqwb6brmwhf5d71fvcbz5dpc-profile/bin/gdb
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libdl-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libdl.so.2" (CRC mismatch).

warning: File "/gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22.8.1-gdb.scm" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22.8.1-gdb.scm
line to your configuration file "/home/mthl/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/mthl/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libpthread-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libpthread.so.0" (CRC mismatch).

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25/lib/libthread_db.so.1".
warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libutil-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libutil.so.1" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libm-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libm.so.6" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libc-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libc.so.6" (CRC mismatch).

warning: the debug information found in "/home/mthl/.guix-profile/lib/debug//gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/libcrypt-2.25.so.debug" does not match "/home/mthl/.guix-profile/lib/libcrypt.so.1" (CRC mismatch).

[New Thread 0x7ffff4bd6700 (LWP 21942)]
[New Thread 0x7ffff4385700 (LWP 21943)]
[New Thread 0x7ffff3b34700 (LWP 21944)]
Throw without catch before boot:
Throw to key encoding-error with args ("scm_to_stringn" "cannot convert narrow string to output locale" 22 #f #f)Aborting.

Thread 1 "gdb" received signal SIGABRT, Aborted.
0x00007ffff5d052c4 in raise () from /home/mthl/.guix-profile/lib/libc.so.6
(gdb) bt
#0 0x00007ffff5d052c4 in raise () from /home/mthl/.guix-profile/lib/libc.so.6
#1 0x00007ffff5d0672a in abort () from /home/mthl/.guix-profile/lib/libc.so.6
#2 0x00007ffff76bae23 in pre_init_throw ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#3 0x00007ffff76d08b6 in vm_regular_engine ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#4 0x00007ffff76d2a38 in scm_call_with_vm ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#5 0x00007ffff76b22bd in scm_to_stringn ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#6 0x00007ffff7666e70 in search_path ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#7 0x00007ffff76685c1 in scm_init_eval_in_scheme ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#8 0x00007ffff7661448 in scm_i_init_guile ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#9 0x00007ffff76b83b0 in scm_i_init_thread_for_guile ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#10 0x00007ffff76b83e9 in with_guile_and_parent ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#11 0x00007ffff7389732 in GC_call_with_stack_base ()
from /home/mthl/.guix-profile/lib/libgc.so.1
#12 0x00007ffff76b8808 in scm_with_guile ()
from /gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14/lib/libguile-2.0.so.22
#13 0x000000000049cad6 in _initialize_guile() ()
#14 0x00000000006de1a3 in initialize_all_files() ()
#15 0x000000000069f27d in gdb_init(char*) ()
#16 0x00000000005fa0be in gdb_main(captured_main_args*) ()
#17 0x0000000000412075 in main ()

Apparently I miss the symbol table of gdb so I don't know how to proceed
next to get more precise information. Help welcome.

When looking at ‘scm_to_stringn’ code and crossing with the actual error
message it looks like the failing instruction is the following:

Toggle snippet (6 lines)
ret = mem_iconveh (scm_i_string_chars (str), ilen,
"ISO-8859-1", enc,
(enum iconv_ilseq_handler) handler, NULL,
&buf, &len);

I am done for today.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 17 Feb 2018 22:16
(name . Mathieu Lirzin)(address . mthl@gnu.org)(address . 30395@debbugs.gnu.org)
87606vjp0t.fsf@gnu.org
Hi,

This is getting interesting. :-)

Mathieu Lirzin <mthl@gnu.org> skribis:

Toggle quote (2 lines)
> ludo@gnu.org (Ludovic Courtès) writes:

[...]

Toggle quote (31 lines)
>> I don’t get it yet. The log shows this:
>>
>> 9543 execve("/gnu/store/x7i79rihhdjkps5fx0f9p2q0svh5a88n-guile-2.2.2/bin/guile", ["/gnu/store/x7i79rihhdjkps5fx0f9p"..., "-c", "(load-compiled \"/gnu/store/w27in"..., "-plugin", "/gnu/store/xjpchnxm9fgg05fqm9apy"..., "-plugin-opt=/gnu/store/xjpchnxm9"..., "-plugin-opt=-fresolution=/tmp/cc"..., "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lgcc_"..., "-plugin-opt=-pass-through=-lc", "-plugin-opt=-pass-through=-lgcc", "-plugin-opt=-pass-through=-lgcc_"..., "--eh-frame-hdr", "-m", "elf_x86_64", "-dynamic-linker", "/gnu/store/3h31zsqxjjg52da5gp3qm"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/0qg64bwn2z3g91b5iw16i"..., "/gnu/store/45rhjm5ryms10frcyrzcd"..., "-L/gnu/store/0qg64bwn2z3g91b5iw1"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/45rhjm5ryms10frcyrz"..., "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "/tmp/cc9aj9M2.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-L/gnu/store/3h31zsqxjjg52da5gp3"..., "-rpath=/gnu/store/3h31zsqxjjg52d"..., ...], 0x113a520 /* 31 vars */) = 0
>>
>> 9543 open("/home/mthl/.guix-profile/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
>>
>> 9543 write(2, "Uncaught exception:\n", 20) = 20
>> 9543 futex(0x7f5d453c6930, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> 9543 futex(0x7f5d43ab0190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> 9543 close(3) = 0
>> 9543 close(4) = 0
>> 9543 munmap(0x7f5d455e8000, 4096) = 0
>> 9543 exit(0) = ?
>> 9539 <... wait4 resumed> 0xcddb20, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
>> 9539 --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
>>
>> This is the execution of ld-wrapper and it terminates with “Uncaught
>> exception”, which isn’t really helpful. Apparently this happens before
>> ‘boot-9.scm’ was even search for.
>>
>> Can you reproduce it by running ‘ld’ directly in that environment? Or
>> better yet, by running ‘guile’? The next thing is to try and do that
>> in gdb…
>
> Yes I can reproduce simply by running ‘guile’ (v2.2.2 and v2.2.3). :-)
>
> LD_LIBRARY_PATH="$HOME/.guix-profile/lib" guile
> Uncaught exception:
> Throw to key encoding-error with args ("scm_to_stringn" "cannot convert
> narrow string to output locale" 22 #f #f)

Awesome. :-)

Toggle quote (5 lines)
> I have tried to set LC_ALL=C, but this doesn't have any impact. Here
> are the outputs of ‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f
> -s 1000 -o OUTPUT guile’ for the failing environment with glibc@2.25 in
> the profile:

[...]

Toggle quote (12 lines)
> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
> 13061 read(3, "# Locale name alias data base.\n# Copyright (C) 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License as published by\n# the Free Software Foundation; either version 2, or (at your option)\n# any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, see <http://www.gnu.org/licenses/>.\n\n# The format of this file is the same as for the corresponding file of\n# the X Window System, which normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A single line contains two fields: an alias and a substitution value.\n# All entries are case independent.\n\n# Note: This file is o"..., 4096) = 2997
> 13061 read(3, "", 4096) = 0
> 13061 close(3) = 0
> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
> 13061 close(3) = 0
> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

How come this ‘gconv-modules’ file doesn’t exist? I have it here.
I have:

Toggle snippet (6 lines)
$ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
$ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y

What about you?

Can you try ‘guix gc --verify’?

FTR these two libcs come from here (on x86_64 with current master):

Toggle snippet (8 lines)
$ ./pre-inst-env guix build -e '((@ (guix packages) package-replacement) (@@ (gnu packages base) glibc))' --no-grafts
/gnu/store/bwbh5zfg06lxla7db6zslmkpc4jjq663-glibc-2.25-debug
/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) glibc-final)'
/gnu/store/w295br3vqqdvmd7hb2ga8h8hk3sd9iiv-glibc-2.25-debug
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25

Toggle quote (8 lines)
> When looking at ‘scm_to_stringn’ code and crossing with the actual error
> message it looks like the failing instruction is the following:
>
> ret = mem_iconveh (scm_i_string_chars (str), ilen,
> "ISO-8859-1", enc,
> (enum iconv_ilseq_handler) handler, NULL,
> &buf, &len);

Yes, without ‘gconv-modules’, libc cannot determine how to convert from
ISO-8859-1.

Thanks for investigating!

Ludo’.
M
M
Mathieu Lirzin wrote on 17 Feb 2018 23:49
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30395@debbugs.gnu.org)
87606v9qq2.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (41 lines)
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
>> 13061 read(3, "# Locale name alias data base.\n# Copyright (C)
>> 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free
>> software; you can redistribute it and/or modify\n# it under the
>> terms of the GNU General Public License as published by\n# the Free
>> Software Foundation; either version 2, or (at your option)\n# any
>> later version.\n#\n# This program is distributed in the hope that it
>> will be useful,\n# but WITHOUT ANY WARRANTY; without even the
>> implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE. See the\n# GNU General Public License for more
>> details.\n#\n# You should have received a copy of the GNU General
>> Public License\n# along with this program; if not, see
>> <http://www.gnu.org/licenses/>.\n\n# The format of this file is the
>> same as for the corresponding file of\n# the X Window System, which
>> normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A
>> single line contains two fields: an alias and a substitution
>> value.\n# All entries are case independent.\n\n# Note: This file is
>> o"..., 4096) = 2997
>> 13061 read(3, "", 4096) = 0
>> 13061 close(3) = 0
>> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
>> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
>> 13061 close(3) = 0
>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
>> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>
> How come this ‘gconv-modules’ file doesn’t exist? I have it here.
> I have:
>
> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>
>
> What about you?

$ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"

There is no corresponding store item, so it seems logical that the
‘gconv-modules’ are not found. :-)

Just in case, I have checked that
‘LD_LIBRARY_PATH="$HOME/.guix-profile/lib" strace -f -s 1000 gdb’ still
has a reference to that glibc:

Toggle snippet (5 lines)
open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Toggle quote (2 lines)
> Can you try ‘guix gc --verify’?

$ guix gc --verify
reading the Nix store...
checking path existence...

$ guix gc --verify=contents
reading the Nix store...
checking path existence...
checking hashes...

What does it mean doctor? Is that cancer?

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 18 Feb 2018 14:51
(name . Mathieu Lirzin)(address . mthl@gnu.org)(address . 30395@debbugs.gnu.org)
87d112iey5.fsf@gnu.org
Mathieu Lirzin <mthl@gnu.org> skribis:

Toggle quote (49 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin <mthl@gnu.org> skribis:
>>
>>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
>>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=2997, ...}) = 0
>>> 13061 read(3, "# Locale name alias data base.\n# Copyright (C)
>>> 1996-2017 Free Software Foundation, Inc.\n#\n# This program is free
>>> software; you can redistribute it and/or modify\n# it under the
>>> terms of the GNU General Public License as published by\n# the Free
>>> Software Foundation; either version 2, or (at your option)\n# any
>>> later version.\n#\n# This program is distributed in the hope that it
>>> will be useful,\n# but WITHOUT ANY WARRANTY; without even the
>>> implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE. See the\n# GNU General Public License for more
>>> details.\n#\n# You should have received a copy of the GNU General
>>> Public License\n# along with this program; if not, see
>>> <http://www.gnu.org/licenses/>.\n\n# The format of this file is the
>>> same as for the corresponding file of\n# the X Window System, which
>>> normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A
>>> single line contains two fields: an alias and a substitution
>>> value.\n# All entries are case independent.\n\n# Note: This file is
>>> o"..., 4096) = 2997
>>> 13061 read(3, "", 4096) = 0
>>> 13061 close(3) = 0
>>> 13061 open("/run/current-system/locale/2.25/fr_FR.utf8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
>>> 13061 fstat(3, {st_mode=S_IFREG|0444, st_size=299, ...}) = 0
>>> 13061 mmap(NULL, 299, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f726d164000
>>> 13061 close(3) = 0
>>> 13061 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
>>> 13061 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>
>> How come this ‘gconv-modules’ file doesn’t exist? I have it here.
>> I have:
>>
>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
>> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>
>>
>> What about you?
>
> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
> guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"
>
> There is no corresponding store item, so it seems logical that the
> ‘gconv-modules’ are not found. :-)

Oh! Now your mission, if you accept it, will be to find where that
5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 comes from. Perhaps what
would help is to diff the “good” and the “bad” strace logs.

Toggle quote (13 lines)
>> Can you try ‘guix gc --verify’?
>
> $ guix gc --verify
> reading the Nix store...
> checking path existence...
>
> $ guix gc --verify=contents
> reading the Nix store...
> checking path existence...
> checking hashes...
>
> What does it mean doctor? Is that cancer?

Everything’s alright, the store is not corrupt, but something else is
amiss.

Thanks,
Ludo’.
M
M
Mathieu Lirzin wrote on 18 Feb 2018 22:51
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 30395@debbugs.gnu.org)
871shi0xvx.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (24 lines)
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> How come this ‘gconv-modules’ file doesn’t exist? I have it here.
>>> I have:
>>>
>>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>>> 03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>> $ wget -q -O - https://berlin.guixsd.org/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc.narinfo | grep NarHash
>>> NarHash: sha256:03la0p9pigf6r33px5nckky9fxvrynvw1fgn9v2l04zlys7k3k2y
>>>
>>>
>>> What about you?
>>
>> $ guix hash -r /gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25
>> guix hash: error: lstat: Aucun fichier ou dossier de ce type: "/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25"
>>
>> There is no corresponding store item, so it seems logical that the
>> ‘gconv-modules’ are not found. :-)
>
> Oh! Now your mission, if you accept it, will be to find where that
> 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 comes from.

I am not clear regarding what to search for, so let me reason at loud.
The following command allows me to find the corresponding derivation:

$ find /gnu/store -name '*.drv' -exec grep 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc {} +
→ /gnu/store/xhg66izrd1ijnaqzk8zxrfn6i5lwgqdi-glibc-2.25.drv

Next to see what packages refers to this derivation I run this:

$ guix gc --referrers /gnu/store/xhg66izrd1ijnaqzk8zxrfn6i5lwgqdi-glibc-2.25.drv
→ /gnu/store/1msbfj9jljqm3zj17fwq0gqzw4vww7h8-glibc-2.25.drv

This corresponds to 38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25 found in
the following “bad” strace log:

Toggle snippet (4 lines)
30147 open("/gnu/store/38kr8xi7nib8rx8xr4gi0w0d8knyca3k-glibc-2.25/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
30147 open("/gnu/store/5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

IIUC 38kr8 is a grafted version of 5x9zx. So what seems to happen is
that there is “something” found in “$HOME/.guix-profile/lib” by the
dynamic loader that contains a reference to '5x9zx' but should be
grafted to refer to '38kr8'. Is that correct?

So the faulty package should be in the outputs corresponding to the
following list:

$ guix gc --referrers /gnu/store/1msbfj9jljqm3zj17fwq0gqzw4vww7h8-glibc-2.25.drv
/gnu/store/2mf7rkp0gs61gffip9k3vzxrqdin2nqw-xdg-mime-database.drv
/gnu/store/64xh3mr0l597j2dwqsaw4y72563mg2n2-gtk-icon-themes.drv
/gnu/store/7d6q1y1py9w6f5ikcq16nl147lw41vdm-ca-certificate-bundle.drv
/gnu/store/8x4mx1vghdgfjcygq34h9160bcvanfd4-manual-database.drv
/gnu/store/d53hf10ljmnavyhy08wxvd91lmkm04xg-gtk-icon-themes.drv
/gnu/store/h0khj5wnfskjrw9r3cmp6rsk5ncj29ws-info-dir.drv
/gnu/store/jamz10xa4hbglbqc49iyj3wp6fm7sq3b-gtk-im-modules.drv
/gnu/store/lx64j3l2j53sav1gzi2flylm0lp5kvym-profile.drv
/gnu/store/q28f7j4qn0fgsc5b51cq5jvpixnd1jrs-fonts-dir.drv
/gnu/store/s01vvhbb2hz76fsch1js5g0p50vbk9y5-xdg-mime-database.drv
/gnu/store/wdzl6xdrdvy196ia9n0mj7f5v5fiyl2r-xdg-desktop-database.drv

Would it possible to grep in the corresponding outputs? For now I have
run tried in my profile without success:

$ grep -RU 5x9zxdmxphmprlchfl3a2y8w5ykcwkjc-glibc-2.25 $HOME/.guix-profile

Toggle quote (3 lines)
> Perhaps what would help is to diff the “good” and the “bad” strace
> logs.

What would be your methodology?

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
L
L
Ludovic Courtès wrote on 14 Mar 2018 18:37
control message for bug #30395
(address . control@debbugs.gnu.org)
87bmfq7e49.fsf@gnu.org
severity 30395 serious
L
L
Ludovic Courtès wrote on 14 Mar 2018 18:37
(address . control@debbugs.gnu.org)
87a7va7e40.fsf@gnu.org
merge 30395 30820
L
L
Ludovic Courtès wrote on 15 Mar 2018 10:03
(address . control@debbugs.gnu.org)
87fu51ww05.fsf@gnu.org
retitle 30395 Chunked store references in compiled code break grafting (again)
L
L
Ludovic Courtès wrote on 16 Mar 2018 09:54
Re: bug#30820: Chunked store references in compiled code break grafting (again)
(address . 30820@debbugs.gnu.org)
87in9wxuwo.fsf@gnu.org
ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (6 lines)
> void foo (char *x, char *y)
> {
> /* MEMCPY (x, str, sizeof str); */
> MEMCPY (y, "this is a literal /gnu/store string", 35);
> }

This was not a correct example because “/gnu/store” must be followed by
at least 34 chars for the patch to work. And indeed, it does work in
this case:

Toggle snippet (20 lines)
$ cat strmov.c
#define _GNU_SOURCE
#include <string.h>
static const char str[] = "MEMpCPY /gnu/store/THIS IS A LONG STRING, A VERY, VERY, VERY LOOOOONG STRING";

extern char *p, *q;

#ifndef MEMCPY
# define MEMCPY memcpy
#endif

void foo (char *x, char *y)
{
/* MEMCPY (x, str, sizeof str); */
MEMCPY (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
$ guix environment --ad-hoc gcc-toolchain@5 -C -- gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs

So the real issue is this:

Toggle quote (4 lines)
> The second issue is that the patch only ever worked with literal
> strings. It does not “see” strings in constant arrays like the ‘str’
> array in the example above.

Ludo’.
L
L
Ludovic Courtès wrote on 21 Mar 2018 00:07
(address . 30820-done@debbugs.gnu.org)
87fu4uibwt.fsf@gnu.org
Hello,

ludo@gnu.org (Ludovic Courtès) skribis:

Toggle quote (6 lines)
> So the real issue is this:
>
>> The second issue is that the patch only ever worked with literal
>> strings. It does not “see” strings in constant arrays like the ‘str’
>> array in the example above.

Good news! Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
with this case:

Toggle snippet (37 lines)
$ cat strmov.c
#define _GNU_SOURCE
#include <string.h>
static const char str[] =
"This is a /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string in a global variable.";

extern char *p, *q;

#ifndef MEMCPY
# define MEMCPY memcpy
#endif

void foo (char *x, char *y)
{
MEMCPY (x, str, sizeof str);
MEMCPY (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}
$ ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-final)'
/gnu/store/wzdyqkdslk1s6f0vi9qw1xha8cniijzs-gcc-5.5.0-lib
/gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0
$ /gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0/bin/gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs
$ NIX_STORE=/foo /gnu/store/46ww5s9zvsw04id438c4drpnwd9m6vl8-gcc-5.5.0/bin/gcc -O2 -c strmov.c
$ objdump -S strmov.o |grep movabs
0: 48 b8 54 68 69 73 20 movabs $0x2073692073696854,%rax
a: 48 ba 74 6f 72 65 2f movabs $0x6565652f65726f74,%rdx
1e: 48 b8 61 20 2f 67 6e movabs $0x732f756e672f2061,%rax
30: 48 b8 65 65 65 65 65 movabs $0x6565656565656565,%rax
4a: 48 b8 65 65 65 65 65 movabs $0x2065656565656565,%rax
58: 48 b8 73 74 72 69 6e movabs $0x6920676e69727473,%rax
66: 48 b8 6e 20 61 20 67 movabs $0x626f6c672061206e,%rax
74: 48 b8 61 6c 20 76 61 movabs $0x6169726176206c61,%rax
82: 48 b8 74 68 69 73 20 movabs $0x2073692073696874,%rax
93: 48 b8 61 20 6c 69 74 movabs $0x61726574696c2061,%rax
a5: 48 b8 6c 20 2f 67 6e movabs $0x732f756e672f206c,%rax

I built everything about to ‘gcc-final’ in ‘core-updates’. I checked
manually that none of the /gnu/store references in libc-2.26.so were
chunked.

For the record, what the patch initially did was to skip code that would
otherwise emit a “block move” when expanding __builtin_memcpy & co.
This patch additionally skips similar code that would replace
__builtin_memcpy calls with memory moves early on, in
‘gimple_fold_builtin_memory_op’, before ‘expand_builtin’ is called.

In the example above, this transformation would lead to the code below
(as seen with ‘-fdump-tree-all’ in the ‘gimple’ phase output):

Toggle snippet (7 lines)
foo (char * x, char * y)
{
MEM[(char * {ref-all})x] = MEM[(char * {ref-all})&str];
memcpy (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}

With the patch we get:

Toggle snippet (7 lines)
foo (char * x, char * y)
{
memcpy (x, &str, 85);
memcpy (y, "this is a literal /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee string", 35);
}

Ludo’.
Closed
R
R
Ricardo Wurmus wrote on 21 Mar 2018 07:39
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bmfic4pz.fsf@elephly.net
Hi Ludo,

Toggle quote (3 lines)
> Good news! Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
> with this case:
[…]
Toggle quote (4 lines)
> I built everything about to ‘gcc-final’ in ‘core-updates’. I checked
> manually that none of the /gnu/store references in libc-2.26.so were
> chunked.

Wow, thank you so much for fixing this!

Is this an option that we can suggest to the GCC developers to
officially support?

--
Ricardo
Closed
L
L
Ludovic Courtès wrote on 21 Mar 2018 21:59
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87605pf8lg.fsf@gnu.org
Hello,

Ricardo Wurmus <rekado@elephly.net> skribis:

Toggle quote (10 lines)
>> Good news! Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
>> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
>> with this case:
> […]
>> I built everything about to ‘gcc-final’ in ‘core-updates’. I checked
>> manually that none of the /gnu/store references in libc-2.26.so were
>> chunked.
>
> Wow, thank you so much for fixing this!

It turned out to be easier than the first time. ;-)

Toggle quote (3 lines)
> Is this an option that we can suggest to the GCC developers to
> officially support?

I don’t know, it’s a Guix-specific hack, and just explaining the
rationale to GCC people may be tricky: they’ll think we’re all mad. ;-)

Ludo’.
Closed
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 30395
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