Segfault when trying to run dummy main

[robinp]

Very likely a bug in my computer (could only try on one), but filing in case anyone has a hint.

WORKSPACE file:

workspace(name = "YOUR_PROJECT_NAME_HERE")

http_archive(
  name = "io_tweag_rules_haskell",
  strip_prefix = "rules_haskell-0.6",
  urls = ["https://github.com/tweag/rules_haskell/archive/v0.6.tar.gz"]
)

load("@io_tweag_rules_haskell//haskell:repositories.bzl", "haskell_repositories")
haskell_repositories()

http_archive(
  name = "io_tweag_rules_nixpkgs",
  strip_prefix = "rules_nixpkgs-0.2.3",
  urls = ["https://github.com/tweag/rules_nixpkgs/archive/v0.2.3.tar.gz"],
)

load("@io_tweag_rules_nixpkgs//nixpkgs:nixpkgs.bzl", "nixpkgs_package")

nixpkgs_package(
  name = "ghc",
  attribute_path = "ghc", # tried "haskell.compiler.ghc844" as well, which should be the same,
)

register_toolchains("//:ghc")

BUILD file:

package(default_visibility = ["//visibility:public"])

load(
  "@io_tweag_rules_haskell//haskell:haskell.bzl",
  "haskell_binary",
  "haskell_library",
  "haskell_toolchain",
)

haskell_toolchain(
  name = "ghc",
  version = "8.4.4",
  tools = "@ghc//:bin",
)

haskell_binary(
  name = "main",
  srcs = ["Main.hs"],
  prebuilt_dependencies = ["base"],
)

Main.hs:

module Main where

main = print "hi"

Symptom:

$ bazel run :main
DEBUG: /home/ron/.cache/bazel/_bazel_ron/2184305ba14cf077afa9db1fa8fcd669/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl:69:5: 
WARNING: Implicitly using '<nixpkgs>' as the location of Nixpkgs.
This is not recommended because it makes the build non-hermetic.
Set which Nixpkgs to use explicitly using 'repository' or 'path' attributes.
    
DEBUG: /home/ron/.cache/bazel/_bazel_ron/2184305ba14cf077afa9db1fa8fcd669/external/io_tweag_rules_haskell/haskell/private/haskell_impl.bzl:50:9: The attribute 'prebuilt_dependencies' has been deprecated,
use the 'haskell_import' rule instead.
INFO: Analysed target //:main (0 packages loaded).
INFO: Found 1 target...
Target //:main up-to-date:
  bazel-bin/main
INFO: Elapsed time: 0.374s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
Segmentation fault (core dumped)

The segfault is from the binary.

$ ldd ./bazel-bin/main
        linux-vdso.so.1 (0x00007ffc93710000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa64c11a000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fa64bf95000)
        libHSbase-4.11.1.0-ghc8.4.4.so => /nix/store/nzcmk7p670j1m1yjqxh20wyp51n4hhl2-ghc-8.4.4/lib/ghc-8.4.4/base-4.11.1.0/libHSbase-4.11.1.0-ghc8.4.4.so (0x00007fa64b3d9000)
        libHSinteger-gmp-1.0.2.0-ghc8.4.4.so => /nix/store/nzcmk7p670j1m1yjqxh20wyp51n4hhl2-ghc-8.4.4/lib/ghc-8.4.4/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0-ghc8.4.4.so (0x00007fa64b196000)
        libHSghc-prim-0.5.2.0-ghc8.4.4.so => /nix/store/nzcmk7p670j1m1yjqxh20wyp51n4hhl2-ghc-8.4.4/lib/ghc-8.4.4/ghc-prim-0.5.2.0/libHSghc-prim-0.5.2.0-ghc8.4.4.so (0x00007fa64aafa000)
        libHSrts-ghc8.4.4.so => /nix/store/nzcmk7p670j1m1yjqxh20wyp51n4hhl2-ghc-8.4.4/lib/ghc-8.4.4/rts/libHSrts-ghc8.4.4.so (0x00007fa64a88d000)
        libffi.so.7 => /nix/store/nzcmk7p670j1m1yjqxh20wyp51n4hhl2-ghc-8.4.4/lib/ghc-8.4.4/rts/libffi.so.7 (0x00007fa64a684000)
        libgmp.so.10 => /nix/store/p0z7zza48ffzcb2riaq26745s02yipfb-gmp-6.1.2/lib/libgmp.so.10 (0x00007fa64a3f0000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007fa64a3e6000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa64a3e1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fa64a21d000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa64c2f1000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fa64a201000)
        libpthread.so.0 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0 (0x00007fa649fe2000)

LD debug info:

$ LD_DEBUG=all ./bazel-bin/main 2> err
Segmentation fault (core dumped)

$ tail err
      4791:
      4791:     calling init: /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0
      4791:

strace tail:

openat(AT_FDCWD, "/nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0pb\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0555, st_size=142424, ...}) = 0
mmap(NULL, 2220624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fde9ec6e000
mprotect(0x7fde9ec87000, 2097152, PROT_NONE) = 0
mmap(0x7fde9ee87000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19000) = 0x7fde9ee87000
mmap(0x7fde9ee89000, 12880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fde9ee89000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fde9ec6c000
arch_prctl(ARCH_SET_FS, 0x7fde9ec6d240) = 0
mprotect(0x7fde9f063000, 16384, PROT_READ) = 0
mprotect(0x7fde9ee87000, 4096, PROT_READ) = 0
mprotect(0x7fde9eea5000, 4096, PROT_READ) = 0
mprotect(0x7fde9f070000, 4096, PROT_READ) = 0
mprotect(0x7fde9f07a000, 4096, PROT_READ) = 0
mprotect(0x7fde9f30d000, 8192, PROT_READ) = 0
mprotect(0x7fde9f517000, 4096, PROT_READ) = 0
mprotect(0x7fdea0da4000, 4096, PROT_READ) = 0
mprotect(0x7fde9f779000, 4096, PROT_READ) = 0
mprotect(0x7fde9fd51000, 4096, PROT_READ) = 0
mprotect(0x7fdea0061000, 8192, PROT_READ) = 0
mprotect(0x7fdea0b78000, 167936, PROT_READ) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fde9ec6a000
mprotect(0x7fdea0f25000, 49152, PROT_READ) = 0
mprotect(0x55648ac4a000, 4096, PROT_READ) = 0
mprotect(0x7fdea0fa2000, 4096, PROT_READ) = 0
munmap(0x7fdea0f35000, 267164)          = 0
set_tid_address(0x7fde9ec6d510)         = 9652
set_robust_list(0x7fde9ec6d520, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fde9ec73cf0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fde9ec7ff10}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fde9ec73d80, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fde9ec7ff10}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7fde00000008} ---
+++ killed by SIGSEGV (core dumped) +++

Nix env:

$ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'
"19.03pre157960.722fcbbb80b"
$ nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable
$ nix-store --verify-path /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27 && echo ok
ok

[guibou]

Hello. Thank you for reporting this.

I tried the setup you gave and it works for me. The possibles differences are:

• I'm using bazel 0.18 from nixpkgs
• I'm using nixpkgs-unstable as channel, but I cannot be sure that I'm using the same as you.

Could you try the following:

• pin your nixpkgs channel so we can be sure we use the same, this can be done using the repository attribute of nixpkgs_package.
• provide your bazel version (if possible from a pinned nixpkgs).

[robinp]

I tried with newer rules_nixpkgs and an explicit repository. WORKSPACE file snippet:

load("@io_tweag_rules_nixpkgs//nixpkgs:nixpkgs.bzl", "nixpkgs_package", "nixpkgs_git_repository")

nixpkgs_git_repository(
  name = "nixpkgs",
  revision = "18.09",
)

nixpkgs_package(
  name = "ghc",
  attribute_path = "haskell.compiler.ghc843",
  repositories = { "nixpkgs": "@nixpkgs//:default.nix" }
)

But segfault remains. Very likely the problem is around my local nix setup, if that's possible. It's userspace mode nix install on Arch.

$ uname -a
Linux gga 4.18.4-arch1-1-ARCH #1 SMP PREEMPT Wed Aug 22 07:33:26 UTC 2018 x86_64 GNU/Linux

Will try on an other machine eventually.

[guibou]

I suppose you tried with rules_nixpkgs 0.3.1. Using this one, I have no issue. The only difference may be the bazel version.

May I also discourage you about using "branch" number for nixpkgs. They are not fixed and can change through time. I'm not even sure I'm having the same 18.09 as yours. It is safer to use a commit hash as revision.

[robinp]

Thank you @guibou! I installed bazel 0.18 and tried to no improvement.

Edit: ignore below, figured I need to give full commit hash like '6a3f5bcb061e1822f50e299f5616a0731636e4e7'.

As for the commit - unrelated issue, but I get the following when trying to use a commit hash instead a tag using revision = "6a3f5bcb061":

$ bazel build :main
Starting local Bazel server and connecting to it...
INFO: SHA256 (https://github.com/NixOS/nixpkgs/archive/6a3f5bcb061.tar.gz) = 90028fdfeff0b44ebd33f0447f9e0971721784eef2bd9733957564fd66fec2a0                                                                                    
ERROR: /tmp/bzlex/BUILD:10:1: no such package '@ghc//': no such package '@nixpkgs//': java.io.IOException: Prefix nixpkgs-6a3f5bcb061 was given, but not found in the archive and referenced by '//:ghc-impl'                    
ERROR: Analysis of target '//:main' failed; build aborted: no such package '@ghc//': no such package '@nixpkgs//': java.io.IOException: Prefix nixpkgs-6a3f5bcb061 was given, but not found in the archive

[guibou]

You should use a full hash. Not the shortened version. I recognize that the UI can be better.

[robinp]

Ok, figured it, my bad. I had bazel installed not from nix, but from a release binary. If you look at the ldd output above, can see that some shared objects are linked to non-nix targets, likely causing discrepancy between ld and other shared objects.

After installing bazel from nix:

$ ldd ./bazel-bin/main
        linux-vdso.so.1 (0x00007ffeeed6c000)
        libstdc++.so.6 => /nix/store/3v5r7fkrbkw2qajadvjbf6p6qriz9p1i-gcc-7.3.0-lib/lib/libstdc++.so.6 (0x00007f2ccf0c7000)
        libm.so.6 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libm.so.6 (0x00007f2cced32000)
        libHSbase-4.11.1.0-ghc8.4.3.so => /nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/libHSbase-4.11.1.0-ghc8.4.3.so (0x00007f2cce178000)
        libHSinteger-gmp-1.0.2.0-ghc8.4.3.so => /nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3/lib/ghc-8.4.3/integer-gmp-1.0.2.0/libHSinteger-gmp-1.0.2.0-ghc8.4.3.so (0x00007f2ccdf35000)
        libHSghc-prim-0.5.2.0-ghc8.4.3.so => /nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3/lib/ghc-8.4.3/ghc-prim-0.5.2.0/libHSghc-prim-0.5.2.0-ghc8.4.3.so (0x00007f2ccd899000)
        libHSrts-ghc8.4.3.so => /nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3/lib/ghc-8.4.3/rts/libHSrts-ghc8.4.3.so (0x00007f2ccd62e000)
        libffi.so.7 => /nix/store/n5i1zdpmk2b1s3z96649xh8f9kr3g96s-ghc-8.4.3/lib/ghc-8.4.3/rts/libffi.so.7 (0x00007f2ccd425000)
        libgmp.so.10 => /nix/store/rxaclc3vhxbzgfllv7601i85z854h48a-gmp-6.1.2/lib/libgmp.so.10 (0x00007f2ccd191000)
        librt.so.1 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/librt.so.1 (0x00007f2cccf89000)
        libdl.so.2 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libdl.so.2 (0x00007f2cccd85000)
        libc.so.6 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/libc.so.6 (0x00007f2ccc9d1000)
        /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib/ld-linux-x86-64.so.2 => /nix/store/g2yk54hifqlsjiha3szr4q3ccmdzyrdv-glibc-2.27/lib64/ld-linux-x86-64.so.2 (0x00007f2ccf44e000)
        libgcc_s.so.1 => /nix/store/3v5r7fkrbkw2qajadvjbf6p6qriz9p1i-gcc-7.3.0-lib/lib/libgcc_s.so.1 (0x00007f2ccc7b9000)
        libpthread.so.0 => /nix/store/fg4yq8i8wd08xg3fy58l6q73cjy8hjr2-glibc-2.27/lib/libpthread.so.0 (0x00007f2ccc59a000)

which shows all shared objects are resolved from nix.

Might be worth a notice in the documentation to provision bazel using nix?

[mboes]

OK I think I know why this happens. When non-Nixpkgs Bazel is used, it autoconfigures the CC toolchain based on whatever it finds in the environment. If you're not inside a nix-shell, it'll just pick up your system's GCC, since that is in the PATH. rules_haskell forces GHC to use whatever Bazel autoconfigured as the CC toolchain (by passing it -pgmc ... on the command-line). But this means that CC code will be compiled, and Haskell code linked, using the system toolchain rather than the one in Nixpkgs, while libHSbase and the like will have been compiled using the Nixpkgs toolchain.

However, the fix here isn't to use Bazel from Nixpkgs. Using the official bindist works fine too, provided we tell Bazel to use the CC toolchain from Nixpkgs. Conversely, Bazel from Nixpkgs fails just like bindist Bazel does when it picks up system GCC.

It's the same old issue rearing its ugly head (see #259, #304, #250). We need to document that if you're going to use a GHC from Nixpkgs, you probably also want GCC from there too (see tweag/rules_nixpkgs#16). Because the two really want to agree on which glibc to use for some reason. There's actually already a ticket for that: #407. So will close this one.

[mboes]

The current best practice is to expose the Nixpkgs GCC/Clang via a nix-shell. But see tweag/rules_nixpkgs#40, which moves everything to the WORKSPACE file.