Differences between container used by "guix build" and "guix environment -C -N"

Differences between container used by "guix build" and "guix environment -C -N"

[Danny Milosavljevic]

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

Hi,

I'm trying to track down the test_process_mask problem in Guix when trying to test rustc.

For that I did:

(apply attached patch)
$ guix build --keep-failed rustc # will fail
$ cd /tmp/guix-build-rustc-1.16.0.drv-0
$ guix environment -C -N rustc
$ bash
$ source environment-variables
$ cd rustc-1.16.0-src
$ ./x86_64-unknown-linux-gnu/stage2/test/stdtest-x86_64-unknown-linux-gnu 2>&1 |grep test_process_mask

will not fail.

Why does it fail in "guix build", then?

[-- Attachment #2: Q --]
[-- Type: application/octet-stream, Size: 3695 bytes --]

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 1217ec71f..81b731979 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -21,13 +21,16 @@
 
 (define-module (gnu packages rust)
   #:use-module (gnu packages base)
+  #:use-module (gnu packages bison)
   #:use-module (gnu packages bootstrap)
   #:use-module (gnu packages cmake)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages curl)
   #:use-module (gnu packages elf)
+  #:use-module (gnu packages flex)
   #:use-module (gnu packages gcc)
   #:use-module (gnu packages jemalloc)
+  #:use-module (gnu packages linux)
   #:use-module (gnu packages llvm)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages python)
@@ -205,22 +208,27 @@ rustc-bootstrap and cargo-bootstrap packages.")
                     "rustc-" version "-src.tar.gz"))
               (sha256
                (base32
-                "1d78jq7mc34n265by68amr9r4nzbiqrilfbwh7gx56ydn4gb6rpr"))))
+                "1d78jq7mc34n265by68amr9r4nzbiqrilfbwh7gx56ydn4gb6rpr"))
+            (modules '((guix build utils)))
+            (snippet
+             `(begin
+                (delete-file-recursively "src/llvm")
+                #t))))
     (build-system gnu-build-system)
     (native-inputs
-     `(("cmake" ,cmake)
+     `(("bison" ,bison) ; For the tests
+       ("cmake" ,cmake)
+       ("flex" ,flex) ; For the tests
        ("git" ,git)
+       ("procps" ,procps) ; For the tests
        ("python-2" ,python-2)
        ("rust-bootstrap" ,rust-bootstrap)
        ("which" ,which)))
     (inputs
      `(("jemalloc" ,jemalloc)
-       ("llvm" ,llvm)))
+       ("llvm" ,llvm-3.9.1)))
     (arguments
-     ;; FIXME: Test failure with llvm 3.8; Update llvm.
-     ;; https://github.com/rust-lang/rust/issues/36835
-     `(#:tests? #f
-       #:phases
+     `(#:phases
        (modify-phases %standard-phases
          (add-after 'unpack 'patch-configure
            (lambda _
@@ -254,7 +262,18 @@ rustc-bootstrap and cargo-bootstrap packages.")
                (substitute* "src/tools/tidy/src/main.rs"
                  (("^.*cargo.*::check.*$") ""))
                (substitute* "src/libstd/process.rs"
-                 (("\"/bin/sh\"") (string-append "\"" bash "/bin/sh\"")))
+                 ;; The newline is intentional.
+                 ;; There's a line length "tidy" check in Rust which would
+                 ;; fail otherwise.
+                 (("\"/bin/sh\"") (string-append "
+\"" bash "/bin/sh\"")))
+               ;(substitute* "src/libstd/sys/unix/process/process_common.rs"
+               ;  (("fn test_process_mask") "#[cfg_attr(target_os = \"linux\", ignore)]
+;fn test_process_mask"))
+;               (substitute* "src/vendor/libc/src/lib.rs"
+;                 (("TODO") "TXDO"))
+               ;; Our ld-wrapper cannot process non-UTF8 bytes in LIBRARY_PATH.
+               (delete-file-recursively "src/test/run-make/linker-output-non-utf8")
                #t)))
          (replace 'configure
            (lambda* (#:key inputs outputs #:allow-other-keys)
@@ -282,6 +301,10 @@ rustc-bootstrap and cargo-bootstrap packages.")
                             "--disable-manage-submodules")))
                ;; Rust uses a custom configure script (no autoconf).
                (zero? (apply system* "./configure" flags)))))
+         (add-before 'check 'set-detail-report
+           (lambda _
+             ; EXTREMELY SLOW (setenv "RUST_BACKTRACE" "1") [100_000 s = 27.7 h vs. 10_0000 s = 2.7 h]
+             #t))
          (add-after 'install 'wrap-rustc
            (lambda* (#:key inputs outputs #:allow-other-keys)
              (let ((out (assoc-ref outputs "out"))

Re: Differences between container used by "guix build" and "guix environment -C -N"

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I'm trying to track down the test_process_mask problem in Guix when trying to test rustc.
>
> For that I did:
>
> (apply attached patch)
> $ guix build --keep-failed rustc # will fail
> $ cd /tmp/guix-build-rustc-1.16.0.drv-0
> $ guix environment -C -N rustc
> $ bash
> $ source environment-variables
> $ cd rustc-1.16.0-src
> $ ./x86_64-unknown-linux-gnu/stage2/test/stdtest-x86_64-unknown-linux-gnu 2>&1 |grep test_process_mask
>
> will not fail.
>
> Why does it fail in "guix build", then?

What does the test do?

I tried to document the differences between the container the daemon
creates and the one you get with “guix environment -C” here:

  https://www.gnu.org/software/guix/manual/html_node/Debugging-Build-Failures.html

Essentially it boils down to /bin/sh available in one case and not in
the other, and UID being zero in one case and something else in the
other.  If you add “-N”, then of course you have networking, which is
not available in the guix-daemon container.

In the end, if you want to be sure what the differences are, you can
compare:

  https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/build.cc#n2062
  and
  https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/linux-container.scm#n209

Hopefully with reepca’s work we can eventually have a single
implementation.  :-)

HTH!

Ludo’.

Re: Differences between container used by "guix build" and "guix environment -C -N"

[Danny Milosavljevic]

Hi Ludo,

it does pretty much the equvalent of this Python program, in Rust:

------------------------
#!/usr/bin/env python3

import os
import subprocess
import signal

signal.pthread_sigmask(signal.SIG_BLOCK, [signal.SIGINT])

p = subprocess.Popen(["cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE)

signal.pthread_sigmask(signal.SIG_UNBLOCK, [signal.SIGINT])

os.kill(p.pid, signal.SIGINT)
stdout, stderr = p.communicate(b"hello\n", timeout=1)
assert stdout == b""
p.wait()
------------------------

The goal of it is to test this feature: Their "Popen" implementation uses something like spawnvp, only they have overwritten it in order to clear the signal mask for the child.

In Rust the test is:

------------------------------------------------------

    fn test_process_mask() {
        unsafe {
            // Test to make sure that a signal mask does not get inherited.
            let mut cmd = Command::new(OsStr::new("cat"));

            let mut set: libc::sigset_t = mem::uninitialized();
            let mut old_set: libc::sigset_t = mem::uninitialized();
            t!(cvt(libc::sigemptyset(&mut set)));
            t!(cvt(sigaddset(&mut set, libc::SIGINT)));
            t!(cvt(libc::pthread_sigmask(libc::SIG_SETMASK, &set, &mut old_set)));

            cmd.stdin(Stdio::MakePipe);
            cmd.stdout(Stdio::MakePipe);

            let (mut cat, mut pipes) = t!(cmd.spawn(Stdio::Null, true));
            let stdin_write = pipes.stdin.take().unwrap();
            let stdout_read = pipes.stdout.take().unwrap();

            t!(cvt(libc::pthread_sigmask(libc::SIG_SETMASK, &old_set,
                                         ptr::null_mut())));

            t!(cvt(libc::kill(cat.id() as libc::pid_t, libc::SIGINT)));
            // We need to wait until SIGINT is definitely delivered. The
            // easiest way is to write something to cat, and try to read it
            // back: if SIGINT is unmasked, it'll get delivered when cat is
            // next scheduled.
            let _ = stdin_write.write(b"Hello");
            drop(stdin_write);

            // Either EOF or failure (EPIPE) is okay.
            let mut buf = [0; 5];
            if let Ok(ret) = stdout_read.read(&mut buf) {
                assert!(ret == 0);
            }

            t!(cat.wait());
        }

------------------------------------------------------

and the implementation that clears the mask is https://github.com/rust-lang/rust/blob/1.16.0/src/libstd/sys/unix/process/process_unix.rs#L144 (line 144ff, bottom of "fn do_exec")

Re: Differences between container used by "guix build" and "guix environment -C -N"

[Ludovic Courtès]

Hi,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> it does pretty much the equvalent of this Python program, in Rust:
>
> ------------------------
> #!/usr/bin/env python3
>
> import os
> import subprocess
> import signal
>
> signal.pthread_sigmask(signal.SIG_BLOCK, [signal.SIGINT])
>
> p = subprocess.Popen(["cat"], stdin=subprocess.PIPE, stdout=subprocess.PIPE)
>
> signal.pthread_sigmask(signal.SIG_UNBLOCK, [signal.SIGINT])
>
> os.kill(p.pid, signal.SIGINT)
> stdout, stderr = p.communicate(b"hello\n", timeout=1)
> assert stdout == b""
> p.wait()
> ------------------------
>
> The goal of it is to test this feature: Their "Popen" implementation uses something like spawnvp, only they have overwritten it in order to clear the signal mask for the child.
>
> In Rust the test is:
>
> ------------------------------------------------------
>
>     fn test_process_mask() {
>         unsafe {
>             // Test to make sure that a signal mask does not get inherited.
>             let mut cmd = Command::new(OsStr::new("cat"));
>
>             let mut set: libc::sigset_t = mem::uninitialized();
>             let mut old_set: libc::sigset_t = mem::uninitialized();
>             t!(cvt(libc::sigemptyset(&mut set)));
>             t!(cvt(sigaddset(&mut set, libc::SIGINT)));
>             t!(cvt(libc::pthread_sigmask(libc::SIG_SETMASK, &set, &mut old_set)));
>
>             cmd.stdin(Stdio::MakePipe);
>             cmd.stdout(Stdio::MakePipe);
>
>             let (mut cat, mut pipes) = t!(cmd.spawn(Stdio::Null, true));
>             let stdin_write = pipes.stdin.take().unwrap();
>             let stdout_read = pipes.stdout.take().unwrap();
>
>             t!(cvt(libc::pthread_sigmask(libc::SIG_SETMASK, &old_set,
>                                          ptr::null_mut())));
>
>             t!(cvt(libc::kill(cat.id() as libc::pid_t, libc::SIGINT)));
>             // We need to wait until SIGINT is definitely delivered. The
>             // easiest way is to write something to cat, and try to read it
>             // back: if SIGINT is unmasked, it'll get delivered when cat is
>             // next scheduled.
>             let _ = stdin_write.write(b"Hello");
>             drop(stdin_write);
>
>             // Either EOF or failure (EPIPE) is okay.
>             let mut buf = [0; 5];
>             if let Ok(ret) = stdout_read.read(&mut buf) {
>                 assert!(ret == 0);
>             }
>
>             t!(cat.wait());
>         }
>
> ------------------------------------------------------
>
> and the implementation that clears the mask is https://github.com/rust-lang/rust/blob/1.16.0/src/libstd/sys/unix/process/process_unix.rs#L144 (line 144ff, bottom of "fn do_exec")

I guess the question would be whether ‘cmd.spawn’ relies on /bin/sh to
spawn processes, in which case “/bin/sh” would need patching like we do
for the ‘system’ function in libc and in other similar situations.  That
doesn’t seem to be the case at first sight.

Ludo’.