GNU bug report logs - #32894
Exception in validate-runpath phase

Previous Next

Package: guix;

Reported by: Julien Lepiller <julien <at> lepiller.eu>

Date: Mon, 1 Oct 2018 12:55:01 UTC

Severity: normal

Done: Julien Lepiller <julien <at> lepiller.eu>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32894 in the body.
You can then email your comments to 32894 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#32894; Package guix. (Mon, 01 Oct 2018 12:55:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Lepiller <julien <at> lepiller.eu>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Mon, 01 Oct 2018 12:55:02 GMT) Full text and rfc822 format available.

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

From: Julien Lepiller <julien <at> lepiller.eu>
To: bug-guix <at> gnu.org
Subject: Exception in validate-runpath phase
Date: Mon, 01 Oct 2018 14:53:51 +0200
Hi,

I'm trying to create a new package for openjdk versions we don't have 
yet. While building openjdk 10 on top of core-updates (because gcc on 
master has a bug that prevents building openjdk 9 and 10), I get a 
stacktrace at the end of the validate-runpath phase:




starting phase `validate-runpath'
validating RUNPATH of 74 binaries in 
"/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib"...
Backtrace:
          11 (primitive-load "/gnu/store/cyxf063m59nb288xnpy94gr4chq…")
In ice-9/eval.scm:
   191:35 10 (_ _)
In srfi/srfi-1.scm:
   863:16  9 (every1 #<procedure 77aaa0 at /gnu/store/p9wwyq2jfq2pi…> …)
In 
/gnu/store/p9wwyq2jfq2piwyc01qgsxm3hsxg2bnv-module-import/guix/build/gnu-build-system.scm:
   799:28  8 (_ _)
   557:16  7 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
In 
/gnu/store/p9wwyq2jfq2piwyc01qgsxm3hsxg2bnv-module-import/guix/build/utils.scm:
   536:23  6 (every* #<procedure validate (directory)> _)
   536:23  5 (every* #<procedure validate-needed-in-runpath (file #…> …)
In ice-9/boot-9.scm:
    829:9  4 (catch srfi-34 #<procedure 1023d40 at /gnu/store/p9wwy…> …)
In 
/gnu/store/p9wwyq2jfq2piwyc01qgsxm3hsxg2bnv-module-import/guix/build/gremlin.scm:
   305:26  3 (_)
In unknown file:
           2 (remove #<procedure libc-library? (lib)> (#))
           1 (find #<procedure 1023b80 at /gnu/store/p9wwyq2jfq2piw…> …)
           0 (string-prefix? "libanl.so" 3659183287175258 #<undefin…> …)

ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 
(expecting string): 3659183287175258




I tried to investigate the issue and I have found that that running 
(validate-needed-in-runpath "/gnu/...") sometimes fails on some files. 
More specifically, it always succeeds on *.so files and on most 
*.debuginfo files, but it fails on these files:

/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib/libjsound.debuginfo
/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib/libjimage.debuginfo
/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib/libjaas_unix.debuginfo
/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib/libawt_xawt.debuginfo

with the following backtrace:



scheme@(guix build gremlin)> (validate-needed-in-runpath 
"/gnu/store/bdgbs6nsb1kzxpqmcxajjkvvkmk5kn72-openjdk-10+46/lib/libjsound.debuginfo")
ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 
(expecting string): 1

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guix build gremlin) [1]> ,bt
In ice-9/boot-9.scm:
    829:9  4 (catch srfi-34 #<procedure 374dd40 at 
guix/build/gremlin.scm:285:2 ()> #<procedure 374dd20 at 
guix/build/gremlin.scm:285:2 (key c)> _)
In guix/build/gremlin.scm:
   305:26  3 (_)
In unknown file:
           2 (remove #<procedure libc-library? (lib)> (1))
           1 (find #<procedure 374db80 at guix/build/gremlin.scm:251:8 
(libc-lib)> ("libanl.so" "libcrypt.so" "libc.so" "libdl.so" "libm.so" 
"libnsl.so" "libp?" ?))
           0 (string-prefix? "libanl.so" 1 #<undefined> #<undefined> 
#<undefined> #<undefined>)



Similarly for libawt_xawt, with the following error message:



In procedure string-prefix?: Wrong type argument in position 2 
(expecting string): 3659183287175258




Then, running:

(elf-dynamic-info (call-with-input-file "libjsoundalsa.debuginfo" 
(compose parse-elf get-bytevector-all)))
$79 = #<<elf-dynamic-info> soname: #f needed: () rpath: () runpath: ()>

(elf-dynamic-info (call-with-input-file "libjsound.debuginfo" (compose 
parse-elf get-bytevector-all)))
$80 = #<<elf-dynamic-info> soname: #f needed: (1) rpath: () runpath: ()>

(elf-dynamic-info (call-with-input-file "libawt_xawt.debuginfo" (compose 
parse-elf get-bytevector-all)))
$81 = #<<elf-dynamic-info> soname: #f needed: (3659183287175258) rpath: 
() runpath: ()>



shows that the number in the exception comes from the needed field. I 
think it should be empty. You can find these three files for comparison 
at:

http://89.234.186.109/guix/libawt_xawt.debuginfo
http://89.234.186.109/guix/libjsoundalsa.debuginfo
http://89.234.186.109/guix/libjsound.debuginfo

Thank you.




Information forwarded to bug-guix <at> gnu.org:
bug#32894; Package guix. (Tue, 02 Oct 2018 12:32:03 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 32894 <at> debbugs.gnu.org
Subject: Re: bug#32894: Exception in validate-runpath phase
Date: Tue, 02 Oct 2018 14:31:10 +0200
Hello Julien,

Julien Lepiller <julien <at> lepiller.eu> skribis:

> Then, running:
>
> (elf-dynamic-info (call-with-input-file "libjsoundalsa.debuginfo"
> (compose parse-elf get-bytevector-all)))
> $79 = #<<elf-dynamic-info> soname: #f needed: () rpath: () runpath: ()>
>
> (elf-dynamic-info (call-with-input-file "libjsound.debuginfo" (compose
> parse-elf get-bytevector-all)))
> $80 = #<<elf-dynamic-info> soname: #f needed: (1) rpath: () runpath: ()>
>
> (elf-dynamic-info (call-with-input-file "libawt_xawt.debuginfo"
> (compose parse-elf get-bytevector-all)))
> $81 = #<<elf-dynamic-info> soname: #f needed: (3659183287175258)
> rpath: () runpath: ()>

The reason we get numbers here (rather than strings) is because the
PT_DYNAMIC segment lacks a string table (DT_STRTAB), and thus there’s
nowhere the DT_NEEDED strings can be looked for, AIUI.

That gremlin.scm lets the number through comes from this bit:

           (if string-table-offset
               (pointer->string
                (bytevector->pointer (elf-bytes elf)
                                     (vma->offset
                                      elf
                                      (+ string-table-offset value))))
               value))

This is a questionable choice, but the crux of the problem is that these
ELF files appear to be corrupt or at least non-conventional.

Even BFD (from Binutils) fails to make sense of it:

--8<---------------cut here---------------start------------->8---
$ readelf -a /tmp/libawt_xawt.debuginfo | grep NEED
$ readelf -a /tmp/libawt_xawt.debuginfo | grep PATH
--8<---------------cut here---------------end--------------->8---

Compare with this (random example):

--8<---------------cut here---------------start------------->8---
$ readelf -a ~/.guix-profile/lib/libEGL.so.1 | grep NEED
  [ 6] .gnu.version_r    VERNEED          0000000000004718  00004718
 0x0000000000000001 (NEEDED)             Shared library: [libxcb-dri2.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11-xcb.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb-dri3.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb-xfixes.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb-present.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb-sync.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libXau.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libXdmcp.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libbsd.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxshmfence.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-client.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgbm.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-server.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libffi.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libexpat.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libdrm.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libglapi.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000006ffffffe (VERNEED)            0x4718
 0x000000006fffffff (VERNEEDNUM)         5
ludo <at> ribbon ~/src/guix$ readelf -a ~/.guix-profile/lib/libEGL.so.1 | grep PATH
 0x000000000000001d (RUNPATH)            Library runpath: [/gnu/store/xmdk5z05kqxpwgagxhlv375x3f82dxb3-libxcb-1.13/lib:/gnu/store/bid7hvpnm8nq04vm4dszywxsw9g2kmf2-libx11-1.6.6/lib:/gnu/store/b9aapwjz2nhri24imzy491fx86ng8jvz-libxau-1.0.8/lib:/gnu/store/07gpi7dx2rjs5v5n12q5b2sk7gxsliih-libxdmcp-1.1.2/lib:/gnu/store/cy16rapipmypb7qj49ncphjkkj9nqkzx-libbsd-0.8.7/lib:/gnu/store/ycj27z17m3n5qj1rwnyxdqkrk7li9712-libxshmfence-1.3/lib:/gnu/store/8w2i20d3gh80x0a7hvbkww8yyn5ky2j8-wayland-1.15.0/lib:/gnu/store/hp2j1cjrca3ghi14ikzhanx8yl41kihp-mesa-18.1.5/lib:/gnu/store/ppsylkcpw2fk2lkzhwjd60xyr9gjl70v-libffi-3.2.1/lib:/gnu/store/70825hjil6070g7cs3mmdnfwmhxgga36-expat-2.2.5/lib:/gnu/store/66h0jfk3k4wavw951ydkzv4x3wwgapkm-libdrm-2.4.92/lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib:/gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..]
--8<---------------cut here---------------end--------------->8---

Then again, these are “.debuginfo” files so perhaps they are the result
of home-made ELF stripping (we don’t have this problem with “.debug”
files created with objcopy & co.).

I can see two short-term “solutions”:

  1. Remove those .debuginfo files prior to the ‘validate-runpath’
     phase.

  2. Set #:validate-runpath? #f.

Could you check in your build logs how those .debuginfo files are produced?

HTH!

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#32894; Package guix. (Wed, 03 Oct 2018 08:15:02 GMT) Full text and rfc822 format available.

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

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32894 <at> debbugs.gnu.org
Subject: Re: bug#32894: Exception in validate-runpath phase
Date: Wed, 03 Oct 2018 10:14:21 +0200
Le 2018-10-02 14:31, ludo <at> gnu.org a écrit :
> Hello Julien,
> 
> [...]
> 
> Then again, these are “.debuginfo” files so perhaps they are the result
> of home-made ELF stripping (we don’t have this problem with “.debug”
> files created with objcopy & co.).
> 
> I can see two short-term “solutions”:
> 
>   1. Remove those .debuginfo files prior to the ‘validate-runpath’
>      phase.
> 
>   2. Set #:validate-runpath? #f.
> 
> Could you check in your build logs how those .debuginfo files are 
> produced?
> 
> HTH!
> 
> Ludo’.

As a workaround, I found that passing --with-native-debug-symbols=zipped 
to the configure script allowed validate-runpath to complete 
successfully. This option is documented as the prefered value for 
distributions, so I think it's a good thing to have. I creates zipped 
versions of these .debuginfo files, so validate-runpath doesn't look at 
them.

There is no mention of debuginfo until the install phase in my build 
log, so I don't know how they are built.




Information forwarded to bug-guix <at> gnu.org:
bug#32894; Package guix. (Mon, 08 Oct 2018 12:23:02 GMT) Full text and rfc822 format available.

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 32894 <at> debbugs.gnu.org
Subject: Re: bug#32894: Exception in validate-runpath phase
Date: Mon, 08 Oct 2018 14:21:46 +0200
Hello,

Julien Lepiller <julien <at> lepiller.eu> skribis:

> Le 2018-10-02 14:31, ludo <at> gnu.org a écrit :
>> Hello Julien,
>>
>> [...]
>>
>> Then again, these are “.debuginfo” files so perhaps they are the result
>> of home-made ELF stripping (we don’t have this problem with “.debug”
>> files created with objcopy & co.).
>>
>> I can see two short-term “solutions”:
>>
>>   1. Remove those .debuginfo files prior to the ‘validate-runpath’
>>      phase.
>>
>>   2. Set #:validate-runpath? #f.
>>
>> Could you check in your build logs how those .debuginfo files are
>> produced?
>>
>> HTH!
>>
>> Ludo’.
>
> As a workaround, I found that passing
> --with-native-debug-symbols=zipped to the configure script allowed
> validate-runpath to complete successfully. This option is documented
> as the prefered value for distributions, so I think it's a good thing
> to have. I creates zipped versions of these .debuginfo files, so
> validate-runpath doesn't look at them.

Hmm OK.  :-)

Is it the files that are zipped, or just .debug sections that are
gzipped?  (Binutils, GDB, etc. support the latter.)

> There is no mention of debuginfo until the install phase in my build
> log, so I don't know how they are built.

OK.

Thanks,
Ludo’.




Reply sent to Julien Lepiller <julien <at> lepiller.eu>:
You have taken responsibility. (Fri, 19 Nov 2021 14:52:02 GMT) Full text and rfc822 format available.

Notification sent to Julien Lepiller <julien <at> lepiller.eu>:
bug acknowledged by developer. (Fri, 19 Nov 2021 14:52:02 GMT) Full text and rfc822 format available.

Message #19 received at 32894-close <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: 32894-close <at> debbugs.gnu.org
Subject: Exception in validate-runpath phase
Date: Fri, 19 Nov 2021 09:51:17 -0500
[Message part 1 (text/plain, inline)]
Since then, we have openjdk 10, and much more recent versions. I don't remember what fixed the issue, but I haven't seen it since then, so closing :)
[Message part 2 (text/html, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 18 Dec 2021 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 91 days ago.

Previous Next


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