Rust 1.19 fails to build on i686 on ‘staging’

Rust 1.19 fails to build on i686 on ‘staging’

[Ludovic Courtès]

Hello,

Rust fails to build on i686 on ‘staging’, so I don’t know if it’s
deterministic (the “unexpected EOF” reminds me of parallel build issues
with half-baked makefiles):

--8<---------------cut here---------------start------------->8---
BUILDING crates_io from crates-io v0.9.0 with features []
> /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/lib/mrust
munmap_chunk(): invalid pointer
src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child process
BUILD FAILED
Backtrace:
           5 (primitive-load "/gnu/store/g1pwkbic91004khxrs8qfnhszs7…")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
   863:16  3 (every1 #<procedure 835a520 at /gnu/store/w8ki740gbcib…> …)
In /gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/gnu-build-system.scm:
   799:28  2 (_ _)
In ice-9/eval.scm:
    619:8  1 (_ #(#(#(#<directory (guile-user) 817e910>) (# # …) …) …))
In /gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/utils.scm:
    616:6  0 (invoke _ . _)

/gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "/gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/tools/bin/minicargo" arguments: ("src/tools/cargo" "--vendor-dir" "src/vendor" "--output-dir" "output/cargo-build" "-L" "output/" "-L" "/gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/lib/mrust" "-j" "1") exit-status: 1 term-signal: #f stop-signal: #f] 80aaa80>)'.
builder for `/gnu/store/380l4b9qdz9knbpnhby0npacmgihbggf-rust-1.19.0.drv' failed with exit code 1
--8<---------------cut here---------------end--------------->8---

(From <https://berlin.guixsd.org/log/qhnlh1hyc8h8505cikmxmc0c3mqv1kgj-rust-1.19.0>.)

Thoughts?

Ludo’.

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Hi Ludo,

> while reading from child process
                     ^^^^^^^^^^^^^

Is that a real Pentium, or qemu on x86_64?  We had some problems with
spawning child processes on the qemu transparent emulator.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

Hi Ludo,

on second thought:

On Mon, 28 Jan 2019 15:39:33 +0100
Ludovic Courtès <ludo@gnu.org> wrote:
> > /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc[...]
> munmap_chunk(): invalid pointer

Maybe the above causes

> src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child process

this.

Might be a memory double-free.  Exactly the kind of thing that Rust is supposed
to prevent is in the Rust compiler in C++ - well, at least the motivation for
having Rust is clear now ;-)

Can you try just

$ /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/lib/mrust

in the build-failed kept source? (possibly with "ulimit -c unlimited" so it dumps core. mrustc is a normal C++ program, so normal debugging ways apply)

Or do I have access to the machine so I can do it?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

Possible use-after free fix in mrustc commits:

https://github.com/thepowersgang/mrustc/commit/a51eea542ae086687ea2c4cb09321785f5cc6269

This was not in the mrustc 0.8.0 release yet.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

Something more serious seems to be up with guix staging because I get,
on trying "make" (after "./configure --localstatedir=/var") inside guix staging
(commit df09e1d6e71f68a8fb44bcc9f13e625f9f9701a5) on x86_64:

Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:29 13 (map1 (((gnu services base)) ((gnu bootloader)) ((…)) …))
   222:29 12 (map1 (((gnu bootloader)) ((gnu system shadow)) ((…)) …))
   222:29 11 (map1 (((gnu system shadow)) ((gnu system nss)) ((…)) …))
   222:29 10 (map1 (((gnu system nss)) ((gnu system locale)) ((…)) …))
   222:17  9 (map1 (((gnu system locale)) ((gnu system pam)) ((…)) …))
  2800:17  8 (resolve-interface (gnu system locale) #:select _ #:hide …)
In ice-9/threads.scm:
    390:8  7 (_ _)
In ice-9/boot-9.scm:
  2726:13  6 (_)
In ice-9/threads.scm:
    390:8  5 (_ _)
In ice-9/boot-9.scm:
  2994:20  4 (_)
   2312:4  3 (save-module-excursion #<procedure 44e0a50 at ice-9/boo…>)
  3014:26  2 (_)
In unknown file:
           1 (primitive-load-path "gnu/system/locale" #<procedure 20…>)
In gnu/system/locale.scm:
    124:0  0 (_)

gnu/system/locale.scm:124:0: In procedure private-lookup: No variable bound to glibc-for-target in module (gnu packages base)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Ricardo Wurmus]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Something more serious seems to be up with guix staging because I get,
> on trying "make" (after "./configure --localstatedir=/var") inside guix staging
> (commit df09e1d6e71f68a8fb44bcc9f13e625f9f9701a5) on x86_64:
>
> Backtrace:
> In ice-9/boot-9.scm:
>    222:29 19 (map1 _)
>    222:29 18 (map1 _)
>    222:29 17 (map1 _)
>    222:29 16 (map1 _)
>    222:29 15 (map1 _)
>    222:29 14 (map1 _)
>    222:29 13 (map1 (((gnu services base)) ((gnu bootloader)) ((…)) …))
>    222:29 12 (map1 (((gnu bootloader)) ((gnu system shadow)) ((…)) …))
>    222:29 11 (map1 (((gnu system shadow)) ((gnu system nss)) ((…)) …))
>    222:29 10 (map1 (((gnu system nss)) ((gnu system locale)) ((…)) …))
>    222:17  9 (map1 (((gnu system locale)) ((gnu system pam)) ((…)) …))
>   2800:17  8 (resolve-interface (gnu system locale) #:select _ #:hide …)
> In ice-9/threads.scm:
>     390:8  7 (_ _)
> In ice-9/boot-9.scm:
>   2726:13  6 (_)
> In ice-9/threads.scm:
>     390:8  5 (_ _)
> In ice-9/boot-9.scm:
>   2994:20  4 (_)
>    2312:4  3 (save-module-excursion #<procedure 44e0a50 at ice-9/boo…>)
>   3014:26  2 (_)
> In unknown file:
>            1 (primitive-load-path "gnu/system/locale" #<procedure 20…>)
> In gnu/system/locale.scm:
>     124:0  0 (_)
>
> gnu/system/locale.scm:124:0: In procedure private-lookup: No variable bound to glibc-for-target in module (gnu packages base)

Did you run “make clean-go” before?

-- 
Ricardo

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

Hi Ricardo,

On Mon, 28 Jan 2019 19:41:50 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> Did you run “make clean-go” before?

Nope.  Did so now - the build of guix staging works now.

Thanks!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Mon, 28 Jan 2019 15:39:33 +0100
> Ludovic Courtès <ludo@gnu.org> wrote:
>> > /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc[...]
>> munmap_chunk(): invalid pointer
>
> Maybe the above causes
>
>> src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child process
>
> this.
>
> Might be a memory double-free.  Exactly the kind of thing that Rust is supposed
> to prevent is in the Rust compiler in C++ - well, at least the motivation for
> having Rust is clear now ;-)

Heh, sounds like it.

> Can you try just
>
> $ /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/lib/mrust
>
> in the build-failed kept source? (possibly with "ulimit -c unlimited" so it dumps core. mrustc is a normal C++ program, so normal debugging ways apply)
>
> Or do I have access to the machine so I can do it?

I don’t know but you could try:

  guix build rust@1.19 -s i686-linux -K

on your x86_64 machine from ‘staging’, and hopefully you’ll get that
error too.

> Possible use-after free fix in mrustc commits:
>
> https://github.com/thepowersgang/mrustc/commit/a51eea542ae086687ea2c4cb09321785f5cc6269

Could be!  We know what to try next.

Thanks for investigating!

Ludo’.

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

Hi Ludo,

running gdb in an i686 transparent qemu emulation gives me:

$ gdb --args /gnu/store/gpc2m2f79rsgy15m65x0s5av7a41rp8b-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/gpc2m2f79rsgy15m65x0s5av7a41rp8b-mrustc-0.8.0/lib/mrust
(gdb) set follow-fork-mode child
(gdb) r
Starting program: /gnu/store/gpc2m2f79rsgy15m65x0s5av7a41rp8b-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/gpc2m2f79rsgy15m65x0s5av7a41rp8b-mrustc-0.8.0/lib/mrust
Parse: V V V
(0.01 s) Parse: DONE
LoadCrates: V V V
(2.33 s) LoadCrates: DONE
Expand: V V V
[Attaching after process 7067 vfork to child process 7071]
[New inferior 2 (process 7071)]
[Detaching vfork parent process 7067 after child exec]
[Inferior 1 (process 7067) detached]
process 7071 is executing new program: /tmp/guix-build-rust-1.19.0.drv-6/rustc-1.19.0-src/output/cargo-build/libserde_derive-1_0_6.hir-plugin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libthread_db.so.1".
munmap_chunk(): invalid pointer

Thread 2.1 "libserde_derive" received signal SIGABRT, Aborted.
[Switching to Thread 0xf7c9de80 (LWP 7071)]
0xf7fd4b59 in ?? ()
(gdb) bt
#0  0xf7fd4b59 in ?? ()
#1  0x00000000 in ?? ()

I've reported it upstream as https://github.com/thepowersgang/mrustc/issues/108 .

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Mark H Weaver]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Rust fails to build on i686 on ‘staging’, so I don’t know if it’s
> deterministic (the “unexpected EOF” reminds me of parallel build issues
> with half-baked makefiles):
>
> BUILDING crates_io from crates-io v0.9.0 with features []
>> /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/fw4yy7cgb5ahs9s2ir00bawnsl5zj7db-mrustc-0.8.0/lib/mrust
> munmap_chunk(): invalid pointer
> src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child process
> BUILD FAILED

FYI, this is not specific to the 'staging' branch.  The same error has
been happening on our 'master' branch since at least September 2018:

  https://hydra.gnu.org/job/gnu/master/rust-1.20.0.i686-linux/all

      Mark

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1.1: Type: text/plain, Size: 8497 bytes --]

Chris and I compared what gets sent by the parent on i686 (where it breaks)
vs on x86_64 (where it doesn't break): There are no differences.

The next step will  be to find out what the child process does with the data.
I suspect that the child processes' input deserializer is broken.

For reference, there are multiple invocations of the child process, so the
debugging process is as follows:

(1) ~/src/guix-staging/guix/pre-inst-env guix environment --pure rust@1.19.0 --ad-hoc gdb less nano
(2) source /tmp/guix-build-rust-1.19.0.drv-0/environment
(3) cd /tmp/guix-build-rust-1.19.0.drv-0/rustc-1.19.0-src
(4) export MRUSTC_DUMP_PROCMACRO=/tmp/x86_64
(4) ~/.guix-profile/bin/gdb --args /gnu/store/pv5280j9fqzchccc37jj4n7yjsv2x4w6-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/pv5280j9fqzchccc37jj4n7yjsv2x4w6-mrustc-0.8.0/lib/mrust
(5) Set a breakpoint on "getenv"
(6) Run
(7) Continue program 4 times at the breakpoint
(8) Inspect /tmp/x86_64

The readable part without the special characters is:

structCrate{pubname:String,pub
                              description:Option<String,>,pub
                                                             max_version:String,}

The child process is:

output/cargo-build/libserde_derive-1_0_6.hir-plugin derive#Deserialize

The backtrace after x86_64's startup is:

#0  0x00007ffff7e178f0 in getenv ()
   from /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libc.so.6
#1  0x000000000044a7df in _ZN3std3sys3imp2os6getenv (arg0=...)
    at output/libstd.hir.o.c:69557
#2  0x000000000044c1fc in _ZN3std3env7_var_os (arg0=...)
    at output/libstd.hir.o.c:56318
#3  0x000000000048789e in _ZN3std3env6var_os$aL$Rs_str$aR (arg0=...)
    at output/libproc_macro.hir.o.c:5682
#4  0x000000000048967b in _ZN10proc_macro4main (arg0=...)
    at output/libproc_macro.hir.o.c:5110
#5  0x00000000004040f3 in _ZN19serde_derive$$1_0_612proc_macro$H4main ()
    at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:35218
#6  0x00000000004af2ec in __rust_maybe_catch_panic (
    arg0=arg0@entry=0x439c10 <_ZN3std9panicking3$H37do_call$aLfn_0_$T0$C$T0$aR>, arg1=arg1@entry=0x7fffffffc130 "\340@@", arg2=arg2@entry=0x7fffffffc120, 
    arg3=arg3@entry=0x7fffffffc128) at output/libpanic_abort.hir.o.c:105
#7  0x000000000044d1e6 in _ZN3std9panicking3try$aL$T0$Cfn_0_$T0$aR (
    arg0=arg0@entry=0x4040e0 <_ZN19serde_derive$$1_0_612proc_macro$H4main>)
    at output/libstd.hir.o.c:63637
#8  0x00000000004510e5 in _ZN3std2rt10lang_start (
    arg0=arg0@entry=0x4040e0 <_ZN19serde_derive$$1_0_612proc_macro$H4main>, 
    arg1=2, arg2=0x7fffffffc328) at output/libstd.hir.o.c:64414
#9  0x0000000000402c14 in main (argc=<optimized out>, argv=<optimized out>)
    at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:86019

The crash is reproducible on i686 by just doing:

/tmp/guix-build-rust-1.19.0.drv-5/rustc-1.19.0-src/output/cargo-build/libserde_derive-1_0_6.hir-plugin 'derive#Deserialize' <~/i686

... without any guix environment or other preparation.

Backtrace on i686 on the crash:

#1  0xf7defa60 in raise () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#2  0xf7df0bd7 in abort () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#3  0xf7e2ff56 in __libc_message () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#4  0xf7e36bbd in malloc_printerr () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#5  0xf7e3713b in munmap_chunk () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#6  0x0804e63e in _ZRK$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:61640
#7  _ZRI$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:175
#8  _ZRI$aL_ZN11collections3vec3Vec$aLu8$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:185
#9  _ZRI$aL_ZN11collections6string6String$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:192
#10 _ZRI$aL_ZN12syn$$0_11_115ident5Ident$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:199
#11 _ZRI$aL_ZN4core6option12Option$HSome$aL_ZN12syn$$0_11_115ident5Ident$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2304
#12 _ZRI$aL_ZN4core6option6Option$aL_ZN12syn$$0_11_115ident5Ident$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2313
#13 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2350
#14 _ZRK$aL_ZN11collections3vec3Vec$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0xffffc47c, arg0@entry=0xffffc558) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:64862
#15 _ZRI$aL_ZN11collections3vec3Vec$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR$aR11$Hdrop_glue (rv=rv@entry=0xffffc47c) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1843
#16 0x0804e758 in _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast12Body$HStruct$aR11$Hdrop_glue (rv=0xffffc478) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1852
#17 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast4Body$aR11$Hdrop_glue (rv=0xffffc478) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1868
#18 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast9Container$aR11$Hdrop_glue (rv=rv@entry=0xffffc3a0) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1882
#19 0x08070393 in _ZN19serde_derive$$1_0_62de25expand_derive_deserialize (arg0=0xffffc57c) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:34299
#20 0x080708a1 in _ZN19serde_derive$$1_0_618derive_deserialize (arg0=...) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:35190
#21 0x080eeb83 in _ZN10proc_macro4main (arg0=...) at output/libproc_macro.hir.o.c:5239
#22 0x0804b114 in _ZN19serde_derive$$1_0_612proc_macro$H4main () at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:35286
#23 0x080eb1fb in __rust_maybe_catch_panic (arg0=0x80bcb20 <_ZN3std9panicking3$H37do_call$aLfn_0_$T0$C$T0$aR>, arg1=0xffffc7b4 "", arg2=0xffffc7ac, arg3=0xffffc7b0) at output/libpanic_abort.hir.o.c:142
#24 0x080d052a in _ZN3std9panicking3try$aL$T0$Cfn_0_$T0$aR (arg0=0x804b100 <_ZN19serde_derive$$1_0_612proc_macro$H4main>) at output/libstd.hir.o.c:63801
#25 0x080d44f3 in _ZN3std2rt10lang_start (arg0=0x804b100 <_ZN19serde_derive$$1_0_612proc_macro$H4main>, arg1=2, arg2=0xffffc904) at output/libstd.hir.o.c:64578
#26 0x08049bc0 in main (argc=2, argv=0xffffc904) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:86165

#6  0x0804e63e in _ZRK$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:61640
warning: Source file is more recent than executable.
61640           var1 = true;    // Local(1) = Constant(true)

(gdb) l 61640
61635           tUNIT var2;     // ()
61636           struct s__ZN5alloc7raw_vec6RawVec$aL_ZN30serde_derive_internals$$0_15_03ast7Variant$aR *var3;   // &::"alloc"::raw_vec::RawVec<::"serde_derive_internals-0_15_0"::ast::Variant/*S*/,>/*S*/
61637           uint8_t *var4;  // *mut u8
61638           struct s__ZN30serde_derive_internals$$0_15_03ast7Variant *var5; // *mut ::"serde_derive_internals-0_15_0"::ast::Variant/*S*/
61639           var0 = 0x70ull; // Local(0) = Constant(112 usize)
61640  !!       var1 = true;    // Local(1) = Constant(true)
61641           var1 = arg0->_1 != 0x0ull;      // Local(1) = BinOp(Field(1, Deref(Argument(0))) NE 0 usize)
61642           if(var1) goto bb1; else goto bb2;
61643           // ^ If( Local(1) : 1, 2)
61644   bb1:

[-- Attachment #1.2: i686 --]
[-- Type: application/octet-stream, Size: 129 bytes --]

[-- Attachment #1.3: x86_64 --]
[-- Type: application/octet-stream, Size: 129 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1.1: Type: text/plain, Size: 4890 bytes --]

Better Backtrace on i686 on the crash:

(gdb) bt
#0  0xf7fd4b59 in __kernel_vsyscall ()
#1  0xf7defa60 in raise () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#2  0xf7df0bd7 in abort () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#3  0xf7e2ff56 in __libc_message () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#4  0xf7e36bbd in malloc_printerr () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#5  0xf7e3713b in munmap_chunk () from /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/libc.so.6
#6  0x0804e63e in _ZRK$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:61640
#7  _ZRI$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:175
#8  _ZRI$aL_ZN11collections3vec3Vec$aLu8$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:185
#9  _ZRI$aL_ZN11collections6string6String$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:192
#10 _ZRI$aL_ZN12syn$$0_11_115ident5Ident$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:199
#11 _ZRI$aL_ZN4core6option12Option$HSome$aL_ZN12syn$$0_11_115ident5Ident$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2304
#12 _ZRI$aL_ZN4core6option6Option$aL_ZN12syn$$0_11_115ident5Ident$aR$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2313
#13 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR11$Hdrop_glue (rv=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:2350
#14 _ZRK$aL_ZN11collections3vec3Vec$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0xffffc47c, arg0@entry=0xffffc558) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:64862
#15 _ZRI$aL_ZN11collections3vec3Vec$aL_ZN30serde_derive_internals$$0_15_03ast5Field$aR$aR11$Hdrop_glue (rv=rv@entry=0xffffc47c) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1843
#16 0x0804e758 in _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast12Body$HStruct$aR11$Hdrop_glue (rv=0xffffc478) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1852
#17 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast4Body$aR11$Hdrop_glue (rv=0xffffc478) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1868
#18 _ZRI$aL_ZN30serde_derive_internals$$0_15_03ast9Container$aR11$Hdrop_glue (rv=rv@entry=0xffffc3a0) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:1882
#19 0x08070393 in _ZN19serde_derive$$1_0_62de25expand_derive_deserialize (arg0=0xffffc57c) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:34299
#20 0x080708a1 in _ZN19serde_derive$$1_0_618derive_deserialize (arg0=...) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:35190
#21 0x080eeb83 in _ZN10proc_macro4main (arg0=...) at output/libproc_macro.hir.o.c:5239
#22 0x0804b114 in _ZN19serde_derive$$1_0_612proc_macro$H4main () at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:35286
#23 0x080eb1fb in __rust_maybe_catch_panic (arg0=0x80bcb20 <_ZN3std9panicking3$H37do_call$aLfn_0_$T0$C$T0$aR>, arg1=0xffffc7b4 "", arg2=0xffffc7ac, arg3=0xffffc7b0) at output/libpanic_abort.hir.o.c:142
#24 0x080d052a in _ZN3std9panicking3try$aL$T0$Cfn_0_$T0$aR (arg0=0x804b100 <_ZN19serde_derive$$1_0_612proc_macro$H4main>) at output/libstd.hir.o.c:63801
#25 0x080d44f3 in _ZN3std2rt10lang_start (arg0=0x804b100 <_ZN19serde_derive$$1_0_612proc_macro$H4main>, arg1=2, arg2=0xffffc904) at output/libstd.hir.o.c:64578
#26 0x08049bc0 in main (argc=2, argv=0xffffc904) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:86165
(gdb) frame 6
#6  0x0804e63e in _ZRK$aL_ZN5alloc7raw_vec6RawVec$aLu8$aR_as__ZN4core3ops4Drop$aR4drop (arg0=0x815c300) at output/cargo-build/libserde_derive-1_0_6.hir-plugin.c:61640
61640           _ZN5alloc4heap17__rust_deallocate( var4, var0, 0x1ull );
(gdb) l
61635   bb1:
61636           var0 = var0 * arg0->_1; // Local(0) = BinOp(Local(0) MUL Field(1, Deref(Argument(0))))
61637           var3 = arg0;    // Local(3) = Borrow(0, Shared, Deref(Argument(0)))
61638           var4 = (uint8_t *)var3->_0._0._0;       // Local(4) = Cast(Field(0, Field(0, Field(0, Deref(Local(3))))) as *mut u8)
61639           var4 = var4;    // Local(4) = Cast(Local(4) as *mut u8)
61640   !!      _ZN5alloc4heap17__rust_deallocate( var4, var0, 0x1ull );
61641           // ^ Call( Local(2) = ::"alloc"::heap::__rust_deallocate( Local(4), Local(0), 1 usize, ), bb2, bb3)
61642   bb2:
61643           ;       // Local(2) = Tuple()
61644           rv = var2;      // Return = Use(Local(2))

Compiler output file is attached.

[-- Attachment #1.2: libserde_derive-1_0_6.hir-plugin.c.gz --]
[-- Type: application/gzip, Size: 507096 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

Hi Chris,

upstream says that compiling rust 1.19.0 works fine for them on i686 with their mrustc
master (since they have applied our variable-length integer decoding patch):

https://github.com/thepowersgang/mrustc/issues/108

>Hmm... works for me, using gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 on linux 4.9.0-8-686-pae
>Compiling cargo ran sucessfully.

Would you have some time and a free computer to be able to build rust 1.19.0 with 

  ./pre-inst-env guix build -K -s i686-linux rust@1.19.0

on guix master with the patch below?

My laptop is currently trying to survive the merge of staging to master and keeps
running out of memory if I try to start a rust build in parallel, even with swap.

The patch to use mrustc master is:

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index e128bb22b..f2a01ded6 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -97,17 +97,35 @@
     (package
       (name "mrustc")
       (version "0.8.0")
+      ;(source (origin
+      ;          (method git-fetch)
+      ;          (uri (git-reference
+      ;                (url "https://github.com/thepowersgang/mrustc.git")
+      ;                (commit (string-append "v" version))))
+      ;          (file-name (git-file-name name version))
+      ;          (sha256
+      ;           (base32
+      ;            "0a7v8ccyzp1sdkwni8h1698hxpfz2sxhcpx42n6l2pbm0rbjp08i"))
+      ;          (patches
+      ;           (search-patches "mrustc-0.8.0-fix-use-after-free.patch"
+      ;                           "mrustc-0.8.0-fix-variable-length-integer-receiving.patch"
+      ;                           "mrustc-0.8.0-fix-emulated-i128-multiply-divide.patch"
+      ;                           "mrustc-0.8.0-fix-i128-overflow-handling.patch"))))
       (source (origin
                 (method git-fetch)
                 (uri (git-reference
                       (url "https://github.com/thepowersgang/mrustc.git")
-                      (commit (string-append "v" version))))
+                      (commit "7b6fa5c6e7d6838c2479280dd3f8d14a43c13899")))
                 (file-name (git-file-name name version))
                 (sha256
                  (base32
-                  "0a7v8ccyzp1sdkwni8h1698hxpfz2sxhcpx42n6l2pbm0rbjp08i"))
+                  "0ki5jv76gmvd0q9y2lixzn4xhy1jamba3f77bk8cz2k4ix6yx5z1"))
                 (patches
-                 (search-patches "mrustc-0.8.0-fix-variable-length-integer-receiving.patch"))))
+                 (search-patches ;"mrustc-0.8.0-fix-use-after-free.patch"
+                                 ;"mrustc-0.8.0-fix-variable-length-integer-receiving.patch"
+                                 ;"mrustc-0.8.0-fix-emulated-i128-multiply-divide.patch"
+                                 ;"mrustc-0.8.0-fix-i128-overflow-handling.patch"
+                                 ))))


Also have to make rust@1.19.0 public or use an "-e" expression.

If you don't have time, no worries, I'll eventually get to it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Chris,
>
> upstream says that compiling rust 1.19.0 works fine for them on i686 with their mrustc
> master (since they have applied our variable-length integer decoding patch):
>
> https://github.com/thepowersgang/mrustc/issues/108

Good to hear they're working with us!

> Would you have some time and a free computer to be able to build rust 1.19.0 with 
>
>   ./pre-inst-env guix build -K -s i686-linux rust@1.19.0
>
> on guix master with the patch below?

I have a spare computer.  It only has 2 GB of RAM and 2 GB of swap,
though.  Will it be enough?

By the way, unfortunately your patch did not apply cleanly to the
current master branch head (c86b5f1b9bdfdd478ba15804f9343feb8d9c019b).
If you think my little computer will be able to crunch through the
build, I'm happy to let it run if you can supply a clean patch.

Thank you!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1.1: Type: text/plain, Size: 920 bytes --]

Hi Chris,

On Tue, 12 Feb 2019 03:47:53 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> > Would you have some time and a free computer to be able to build rust 1.19.0 with 
> >
> >   ./pre-inst-env guix build -K -s i686-linux rust@1.19.0
> >
> > on guix master with the patch below?  
> 
> I have a spare computer.  It only has 2 GB of RAM and 2 GB of swap,
> though.  Will it be enough?

If you don't run anything else on it (Firefox etc), it should be barely enough.

> By the way, unfortunately your patch did not apply cleanly to the
> current master branch head (c86b5f1b9bdfdd478ba15804f9343feb8d9c019b).
> If you think my little computer will be able to crunch through the
> build, I'm happy to let it run if you can supply a clean patch.

Yeah, sorry, it was cut.  I've cleaned it up and attached the new version.

It should apply to master using "patch -p1 < mrustc-master.patch".

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: mrustc-master.patch --]
[-- Type: text/x-patch, Size: 2685 bytes --]

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 501736d89..78705103b 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -101,11 +101,11 @@
                 (method git-fetch)
                 (uri (git-reference
                       (url "https://github.com/thepowersgang/mrustc.git")
-                      (commit (string-append "v" version))))
+                      (commit "7b6fa5c6e7d6838c2479280dd3f8d14a43c13899")))
                 (file-name (git-file-name name version))
                 (sha256
                  (base32
-                  "0a7v8ccyzp1sdkwni8h1698hxpfz2sxhcpx42n6l2pbm0rbjp08i"))))
+                  "0ki5jv76gmvd0q9y2lixzn4xhy1jamba3f77bk8cz2k4ix6yx5z1"))))
       (outputs '("out" "cargo"))
       (build-system gnu-build-system)
       (inputs
@@ -118,6 +118,7 @@
           ,(rust-source "1.19.0" "0l8c14qsf42rmkqy92ahij4vf356dbyspxcips1aswpvad81y8qm"))))
       (arguments
        `(#:test-target "local_tests"
+         #:strip-binaries? #f
          #:make-flags (list (string-append "LLVM_CONFIG="
                                            (assoc-ref %build-inputs "llvm")
                                            "/bin/llvm-config"))
@@ -127,6 +128,9 @@
             (lambda _
               (substitute* "Makefile"
                (("shell date") "shell date -d @1"))
+              (substitute* "Makefile"
+               (("-g ") "-g3 ")
+               (("-O2") ""))
               #t))
            (add-after 'patch-date 'unpack-target-compiler
              (lambda* (#:key inputs outputs #:allow-other-keys)
@@ -184,7 +188,7 @@ safety and thread safety guarantees.")
       ;; Dual licensed.
       (license (list license:asl2.0 license:expat)))))
 
-(define rust-1.19
+(define-public rust-1.19
   (package
     (name "rust")
     (version "1.19.0")
@@ -308,12 +312,14 @@ test = { path = \"../libtest\" }
                (setenv "CFG_VERSION" #f)
                (setenv "CFG_PREFIX" #f)
                (setenv "CFG_LIBDIR_RELATIVE" #f)
+               ; Fails:
                (invoke (string-append rustc-bootstrap "/tools/bin/minicargo")
                        "src/tools/cargo" "--vendor-dir" "src/vendor"
                        "--output-dir" "output/cargo-build"
                        "-L" "output/"
                        "-L" (string-append rustc-bootstrap "/lib/mrust")
                        "-j" "1")
+               ;(invoke "eee")
                ;; Now use the newly-built rustc to build the libraries.
                ;; One day that could be replaced by:
                ;; (invoke "output/cargo-build/cargo" "build"

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

>> > Would you have some time and a free computer to be able to build
>> > rust 1.19.0 with
>> >
>> >   ./pre-inst-env guix build -K -s i686-linux rust@1.19.0
>> >
>> > on guix master with the patch below?  
>> 
>> I have a spare computer.  It only has 2 GB of RAM and 2 GB of swap,
>> though.  Will it be enough?
>
> If you don't run anything else on it (Firefox etc), it should be
> barely enough

Sounds good.  I've successfully applied the patch to a clean checkout of
Guix at the current master branch head
(c7cf43ddec9be5389d3a2623d6414d9b55354f64).  I've kicked off a build on
an x86_64-linux system (Guix running on a Debian foreign distro) via:

  guix environment --pure guix
  # And then, in the pure environment:
  ./bootstrap && ./configure --localstatedir=/var && make -j 1 && echo built guix > /tmp/mylog && time ./pre-inst-env guix build --max-jobs=1 --cores=1 -K -s i686-linux rust@1.19.0

It's gonna take a long time to finish.  I'll let you know how it goes!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Hi Danny,

> Sounds good.  I've successfully applied the patch to a clean checkout of
> Guix at the current master branch head
> (c7cf43ddec9be5389d3a2623d6414d9b55354f64).  I've kicked off a build on
> an x86_64-linux system (Guix running on a Debian foreign distro) via:
>
>   guix environment --pure guix
>   # And then, in the pure environment:
>   ./bootstrap && ./configure --localstatedir=/var && make -j 1 && echo
> built guix > /tmp/mylog && time ./pre-inst-env guix build --max-jobs=1
> --cores=1 -K -s i686-linux rust@1.19.0
>
> It's gonna take a long time to finish.  I'll let you know how it goes!

The build failed because it ran out of memory.  This machine won't work.
I've started the build on another machine with more memory, and I'll let
you know how it goes.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 2797 bytes --]

Hi Danny,

Chris Marusich <cmmarusich@gmail.com> writes:

> Hi Danny,
>
>> Sounds good.  I've successfully applied the patch to a clean checkout of
>> Guix at the current master branch head
>> (c7cf43ddec9be5389d3a2623d6414d9b55354f64).  I've kicked off a build on
>> an x86_64-linux system (Guix running on a Debian foreign distro) via:
>>
>>   guix environment --pure guix
>>   # And then, in the pure environment:
>>   ./bootstrap && ./configure --localstatedir=/var && make -j 1 && echo
>> built guix > /tmp/mylog && time ./pre-inst-env guix build --max-jobs=1
>> --cores=1 -K -s i686-linux rust@1.19.0
>>
>> It's gonna take a long time to finish.  I'll let you know how it goes!
>
> The build failed because it ran out of memory.  This machine won't work.
> I've started the build on another machine with more memory, and I'll let
> you know how it goes.

The build failed after 3 hours.  I've attached the full build log.  The
final bit was:

--8<---------------cut here---------------start------------->8---
Backtrace:
           6 (primitive-load "/gnu/store/0q88w9lgl5maks0qcrymkcymv87…")
In ice-9/eval.scm:
   191:35  5 (_ _)
In srfi/srfi-1.scm:
   863:16  4 (every1 #<procedure 83625d0 at /gnu/store/w8ki740gbcib…> …)
In /gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/gnu-build-system.scm:
   799:28  3 (_ _)
In ice-9/eval.scm:
    619:8  2 (_ #(#(#(#<directory (guile-user) 817e910>) (# # …) …) …))
In ice-9/boot-9.scm:
   260:13  1 (for-each #<procedure 8bf0770 at ice-9/eval.scm:333:13…> …)
In /gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/utils.scm:
    616:6  0 (invoke _ . _)

/gnu/store/w8ki740gbcibbifmljwjpd0vmix5jw8q-module-import/guix/build/utils.scm:616:6: In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "output/rustc-build/rustc" arguments: ("-C" "linker=/gnu/store/mhkpjv29ssmr4cm71654x4c5gm40ncjb-gcc-5.5.0/bin/gcc" "-Z" "force-unstable-if-unmarked" "-L" "output/target-libs" "src/libcore/lib.rs" "-o" "output/target-libs/libcore.rlib") exit-status: #f term-signal: 8 stop-signal: #f] 8181580>)'.
--8<---------------cut here---------------end--------------->8---

My understanding is that "term-signal: 8" means the process (rustc) was
terminated by signal 8 (SIGFPE on my system according to "kill -l").  Is
that right?

I looked in the failed build directory, but I couldn't find a core
dump.  When I manually ran the command...

/gnu/store/jxq[...]-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs [...]

...it actually succeeded.

Does this tell you anything useful?  I will keep the build directory
around for now, so please let me know if you'd like me to check anything
else.

-- 
Chris

[-- Attachment #1.2: 49wkd7l2bk8yszgv9i0y6vr26k892l-rust-1.19.0.drv.bz2 --]
[-- Type: application/octet-stream, Size: 182963 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

Hi Chris,

On Wed, 13 Feb 2019 20:35:51 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> My understanding is that "term-signal: 8" means the process (rustc) was
> terminated by signal 8 (SIGFPE on my system according to "kill -l").  Is
> that right?

According to upstream [1], it might be SIGABRT, but I see your reasoning.

> I looked in the failed build directory, but I couldn't find a core
> dump.  When I manually ran the command...
> 
> /gnu/store/jxq[...]-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs [...]
> 
> ...it actually succeeded.

Does that mean in an i686-linux guix environment?

If so, that's very good to know and it could be a good workaround to keep going!

Did you source the environment-variables, too?

[1] https://github.com/thepowersgang/mrustc/issues/78#issuecomment-416073674

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 4136 bytes --]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> On Wed, 13 Feb 2019 20:35:51 -0800
> Chris Marusich <cmmarusich@gmail.com> wrote:
>
>> I looked in the failed build directory, but I couldn't find a core
>> dump.  When I manually ran the command...
>> 
>> /gnu/store/jxq[...]-mrustc-0.8.0/bin/mrustc
>> src/tools/cargo/src/bin/cargo.rs [...]
>> 
>> ...it actually succeeded.
>
> Does that mean in an i686-linux guix environment?
>
> If so, that's very good to know and it could be a good workaround to keep going!
>
> Did you source the environment-variables, too?

Here's more info about what I did.  On my x86_64-linux Guix System
machine, where the build failed, I ran the following commands:

--8<---------------cut here---------------start------------->8---
cd /tmp/guix-build-rust-1.19.0.drv-0
. environment-variables
cd rustc-1.19.0-src/
/gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs --crate-name cargo --crate-type bin --crate-tag 0_20_0 -g --cfg debug_assertions -O -o output/cargo-build/cargo -L output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.hir --extern crates_io=output/cargo-build/libcrates_io-0_9_0.hir --extern crossbeam=output/cargo-build/libcrossbeam-0_2_10.hir --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern docopt=output/cargo-build/libdocopt-0_7_0.hir --extern env_logger=output/cargo-build/libenv_logger-0_4_2.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern filetime=output/cargo-build/libfiletime-0_1_10.hir --extern flate2=output/cargo-build/libflate2-0_2_19.hir --extern fs2=output/cargo-build/libfs2-0_4_1.hir --extern git2=output/cargo-build/libgit2-0_6_6.hir --extern git2_curl=output/cargo-build/libgit2_curl-0_7_0.hir --extern glob=output/cargo-build/libglob-0_2_11.hir --extern jobserver=output/cargo-build/libjobserver-0_1_6.hir --extern libc=output/cargo-build/liblibc-0_2_22.hir --extern libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.hir --extern log=output/cargo-build/liblog-0_3_7.hir --extern num_cpus=output/cargo-build/libnum_cpus-1_4_0.hir --extern rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.hir --extern scoped_tls=output/cargo-build/libscoped_tls-0_1_0.hir --extern semver=output/cargo-build/libsemver-0_7_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_ignored=output/cargo-build/libserde_ignored-0_0_3.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern shell_escape=output/cargo-build/libshell_escape-0_1_3.hir --extern tar=output/cargo-build/libtar-0_4_13.hir --extern tempdir=output/cargo-build/libtempdir-0_3_5.hir --extern term=output/cargo-build/libterm-0_4_5.hir --extern toml=output/cargo-build/libtoml-0_4_1.hir --extern url=output/cargo-build/liburl-1_4_0.hir --extern openssl=output/cargo-build/libopenssl-0_9_12.hir -L output -L /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/lib/mrust
--8<---------------cut here---------------end--------------->8---

The last command exited with exit code 0.  For your reference, I've
attached the output, also.

The mrustc program is a 32-bit executable, which makes sense since the
build was for an i686-linux system:

--8<---------------cut here---------------start------------->8---
$ file /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/bin/mrustc
/gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/bin/mrustc: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /gnu/store/qk8irm5yp2khq4dj7zcpcaa1g87pfyvw-glibc-2.28/lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped
--8<---------------cut here---------------end--------------->8---

Do I need to do something special to attempt to run this mrustc program
in "i686-linux" mode?  For example, I see that the guix-daemon sets the
Linux kernel's personality to 32 bits by invoking
personality(PER_LINUX32) in nix/libstore/build.cc.  Maybe mrustc won't
fail unless we do that first?

-- 
Chris

[-- Attachment #1.2: output.gz --]
[-- Type: application/octet-stream, Size: 1728 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 5629 bytes --]

Hi Chris,

On Fri, 15 Feb 2019 01:11:02 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> Here's more info about what I did.  On my x86_64-linux Guix System
> machine, where the build failed, I ran the following commands:
> 
> --8<---------------cut here---------------start------------->8---
> cd /tmp/guix-build-rust-1.19.0.drv-0
> . environment-variables
> cd rustc-1.19.0-src/
> /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs --crate-name cargo --crate-type bin --crate-tag 0_20_0 -g --cfg debug_assertions -O -o output/cargo-build/cargo -L output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.hir --extern crates_io=output/cargo-build/libcrates_io-0_9_0.hir --extern crossbeam=output/cargo-build/libcrossbeam-0_2_10.hir --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern docopt=output/cargo-build/libdocopt-0_7_0.hir --extern env_logger=output/cargo-build/libenv_logger-0_4_2.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern filetime=output/cargo-build/libfiletime-0_1_10.hir --extern flate2=output/cargo-build/libflate2-0_2_19.hir --extern fs2=output/cargo-build/libfs2-0_4_1.hir --extern git2=output/cargo-build/libgit2-0_6_6.hir --extern git2_curl=output/cargo-build/libgit2_curl-0_7_0.hir --extern glob=output/cargo-build/libglob-0_2_11.hir --extern jobserver=output/cargo-build/libjobserver-0_1_6.hir --extern libc=output/cargo-build/liblibc-0_2_22.hir --extern libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.hir --extern log=output/cargo-build/liblog-0_3_7.hir --extern num_cpus=output/cargo-build/libnum_cpus-1_4_0.hir --extern rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.hir --extern scoped_tls=output/cargo-build/libscoped_tls-0_1_0.hir --extern semver=output/cargo-build/libsemver-0_7_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_ignored=output/cargo-build/libserde_ignored-0_0_3.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern shell_escape=output/cargo-build/libshell_escape-0_1_3.hir --extern tar=output/cargo-build/libtar-0_4_13.hir --extern tempdir=output/cargo-build/libtempdir-0_3_5.hir --extern term=output/cargo-build/libterm-0_4_5.hir --extern toml=output/cargo-build/libtoml-0_4_1.hir --extern url=output/cargo-build/liburl-1_4_0.hir --extern openssl=output/cargo-build/libopenssl-0_9_12.hir -L output -L /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/lib/mrust
> --8<---------------cut here---------------end--------------->8---

> Do I need to do something special to attempt to run this mrustc program
> in "i686-linux" mode?  For example, I see that the guix-daemon sets the

> Linux kernel's personality to 32 bits by invoking
> personality(PER_LINUX32) in nix/libstore/build.cc.  Maybe mrustc won't
> fail unless we do that first?

Oh, that might be related.  I didn't think of that.

Can you try the following (if you didn't already)?

$ guix environment --pure -s i686-linux rust@1.19.0
[env]$ cd /tmp/guix-build-rust-1.19.0.drv-0
[env]$ . environment-variables
[env]$ cd rustc-1.19.0-src/
[env]$ /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/bin/cargo.rs --crate-name cargo --crate-type bin --crate-tag 0_20_0 -g --cfg debug_assertions -O -o output/cargo-build/cargo -L output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.hir --extern crates_io=output/cargo-build/libcrates_io-0_9_0.hir --extern crossbeam=output/cargo-build/libcrossbeam-0_2_10.hir --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern docopt=output/cargo-build/libdocopt-0_7_0.hir --extern env_logger=output/cargo-build/libenv_logger-0_4_2.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern filetime=output/cargo-build/libfiletime-0_1_10.hir --extern flate2=output/cargo-build/libflate2-0_2_19.hir --extern fs2=output/cargo-build/libfs2-0_4_1.hir --extern git2=output/cargo-build/libgit2-0_6_6.hir --extern git2_curl=output/cargo-build/libgit2_curl-0_7_0.hir --extern glob=output/cargo-build/libglob-0_2_11.hir --extern jobserver=output/cargo-build/libjobserver-0_1_6.hir --extern libc=output/cargo-build/liblibc-0_2_22.hir --extern libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.hir --extern log=output/cargo-build/liblog-0_3_7.hir --extern num_cpus=output/cargo-build/libnum_cpus-1_4_0.hir --extern rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.hir --extern scoped_tls=output/cargo-build/libscoped_tls-0_1_0.hir --extern semver=output/cargo-build/libsemver-0_7_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_ignored=output/cargo-build/libserde_ignored-0_0_3.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern shell_escape=output/cargo-build/libshell_escape-0_1_3.hir --extern tar=output/cargo-build/libtar-0_4_13.hir --extern tempdir=output/cargo-build/libtempdir-0_3_5.hir --extern term=output/cargo-build/libterm-0_4_5.hir --extern toml=output/cargo-build/libtoml-0_4_1.hir --extern url=output/cargo-build/liburl-1_4_0.hir --extern openssl=output/cargo-build/libopenssl-0_9_12.hir -L output -L /gnu/store/jxq5p3mx2gavj7hws1drz3pndn87lqrl-mrustc-0.8.0/lib/mrust

(i.e. the things you did before, just inside a i686-linux guix environment.  That only provides minimal--almost no--isolation from the host, so it should allow us to test whether the personality is the only possible culprit)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1.1: Type: text/plain, Size: 1058 bytes --]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Can you try the following (if you didn't already)?
>
> [...]
>
> (i.e. the things you did before, just inside a i686-linux guix
> environment.  That only provides minimal--almost no--isolation from
> the host, so it should allow us to test whether the personality is the
> only possible culprit)

Did you mean to say that by using a pure guix environment, we can
achieve a high degree of isolation?

I tried what you suggested.  The mrustc invocation still succeeded.

Just for fun, I also made a simple wrapper program that lets me run
another program using the LINUX32 personality (see attached).  I think I
programmed it correctly, but C is not (yet!) my forte, so if I made an
error, please let me know.  From within the same pure environment, I
used this wrapper program to invoke mrustc in the same way, and it
_still_ succeeded.  That surprised me, since I expected it to fail.

Can you think of any other way I can try to reproduce the issue?

-- 
Chris

[-- Attachment #1.2: with_linux32_personality.c --]
[-- Type: application/octet-stream, Size: 1016 bytes --]

#include <sys/personality.h>
#include <stdio.h>
#include <unistd.h>

int main (int argc, char *argv[]) {
  // Allow at most 100 arguments.
  const int ARGS_SIZE = 102;
  // The first element of args is reserved for the target program
  // name, and the last element is reserved for the NULL pointer.
  char *args[ARGS_SIZE];
  if (argc > ARGS_SIZE) {
    // We can't fit everything into into args.
    printf("Specify 1 program name and at most %d arguments\n", ARGS_SIZE - 2);
    return 2;
  }
  printf("argc: %d\n", argc);
  printf("argv[0]: %s\n", argv[0]);
  char *target_program = argv[1];
  if (NULL == target_program) {
    puts("Specify a program to run");
    return 2;
  }
  for (int i = 0; i < ARGS_SIZE; i++) {
    args[i] = argv[i + 1];
    printf("args[%d]: %s\n", i, args[i]);
    if (NULL == args[i]) {
      break;
    }
  }
  if (personality(PER_LINUX32) == -1) {
    perror("failed to set personality");
    return 1;
  }
  puts("\n--- Executing program ---\n");
  execv(target_program, args);
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]

Hi Chris,

On Sat, 16 Feb 2019 02:53:30 -0800
Chris Marusich <cmmarusich@gmail.com> wrote:

> > (i.e. the things you did before, just inside a i686-linux guix
> > environment.  That only provides minimal--almost no--isolation from
> > the host, so it should allow us to test whether the personality is the
> > only possible culprit)  
> 
> Did you mean to say that by using a pure guix environment, we can
> achieve a high degree of isolation?

* "guix environment" provides very low isolation (almost none)
* "guix environment --pure" provides better isolation by at least removing
things from $PATH which aren't supposed to be there.
* "guix environment -C" provides very good isolation by creating a new
initially-empty container.

What I meant is that "guix environment -s i686-linux" is very different
from guix-daemon (especially it does not set the personality) and might
allow us to proceed without error, or with a different error.

But apparently the actual problem is that now it always succeeds.

Today I think we should reproduce the guix-daemon environment as closely as
possible in order to make it fail again--and then use the setup right before
it started failing again.

In this case if we wanted to have a similar environment to the guix-daemon,
I think "guix environment -C" would be the most similar - and should fail.
I'm not sure whether guix environment -C sets the personality.  If not,
then your program should be good for setting the personality.

Your program could be simpler if it just used execv(argv[1], argv + 1)
(or execv(argv[1], &argv[1]))
instead of copying the argument vector; if one wants to skip elements at
the front of an array, using the fact that arrays elements are sequential
in C, without gaps, ordered by increasing index, can be very useful.

> I tried what you suggested.  The mrustc invocation still succeeded.

So it always succeeds outside guix-daemon container (does that include
"guix environment -C" ?), but doesn't succeed inside a guix-daemon
container, is that correct?

> Just for fun, I also made a simple wrapper program that lets me run
> another program using the LINUX32 personality (see attached).  I think I
> programmed it correctly, but C is not (yet!) my forte, so if I made an
> error, please let me know.

From within the same pure environment, I
> used this wrapper program to invoke mrustc in the same way, and it
> _still_ succeeded.  That surprised me, since I expected it to fail.

That's strange.  Then maybe the personality is not the reason.

> Can you think of any other way I can try to reproduce the issue?

I'd try 

guix environment -s i686-linux -C rust@1.19.0
And then try to build it in there (or only run the same steps you
ran before--should be enough).

Thanks for looking into it.  Apparently it seems to be possible to get
working--it's just a matter of tuning the environment (maybe even
only by removing things).

(If it is the personality, I suspect that it changes the system call
interface and maybe mrustc assumes the x86_64 syscall interface at
all times)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 228 bytes --]

Hi,

can we give thepowersgang (author of mrustc) an ssh account on a guix machine
reachable from the internet, for debugging this problem?

It would be good if "guix build -K" kept the sources on that machine.

Thanks!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> can we give thepowersgang (author of mrustc) an ssh account on a guix machine
> reachable from the internet, for debugging this problem?
>
> It would be good if "guix build -K" kept the sources on that machine.

Is/are the thepowersgang still willing to help us out?  Ludo, what do
you think about Danny's request?

While we wait, thepowersgang can in theory install Guix as usual on any
GNU/Linux system and reproduce the issue, right Danny?  If you're in
touch with them, maybe you could suggest that.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Rust 1.19 fails to build on i686 on ‘staging’

[Ricardo Wurmus]

Chris Marusich <cmmarusich@gmail.com> writes:

> Danny Milosavljevic <dannym@scratchpost.org> writes:
>
>> can we give thepowersgang (author of mrustc) an ssh account on a guix machine
>> reachable from the internet, for debugging this problem?
>>
>> It would be good if "guix build -K" kept the sources on that machine.
>
> Is/are the thepowersgang still willing to help us out?  Ludo, what do
> you think about Danny's request?

Is it really necessary?  We have bayfront as a developer machine, but
I’m only comfortable granting shell access to members of the Guix
community.

> While we wait, thepowersgang can in theory install Guix as usual on any
> GNU/Linux system and reproduce the issue, right Danny?  If you're in
> touch with them, maybe you could suggest that.

I think this is a better option.

--
Ricardo