Skip to content

Inconsistency detected by ld.so: dl-lookup.c: 966: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed! #368

@ghost

Description

Describe the bug

During the nixpkgs bootstrap process, binaries which link against a patchelf'ed librt.so.1 abort with:

Inconsistency detected by ld.so: dl-lookup.c: 966: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed! #368 

Steps To Reproduce

  1. Set your NIX_PATH explicitly, if you have not yet done so (i.e. such that $NIX_PATH/nixpkgs/ points to a git checkout of nixpkgs).

  2. Execute these commands to build the mips64el bootstrap tools, mips64el-nix, and launch a mips64el qemu VM:

# Assumes you have set $NIX_PATH explicitly.  If not, do so.

cd $NIX_PATH/nixpkgs

git fetch https://github.com/a-m-joseph/nixpkgs patchelf-issue-368
git switch -c patchelf-issue-368 FETCH_HEAD

cd /tmp  # or elsewhere
git clone -b patchelf-issue https://github.com/a-m-joseph/mips64-nixpkgs-qemu
cd mips64-nixpkgs-qemu
nix-shell shell.nix --argstr NIXPATH $NIX_PATH

Once the VM boots to a root shell, paste this command:

./demo.sh

You should get:

Inconsistency detected by ld.so: dl-lookup.c: 966: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed!
error: builder for '/nix/store/76h8qjiv0kr99n87g01qz3sq4z5svikv-bootstrap-tools.drv' failed with exit code 127

This is due to the attempt to patchelf --set-rpath librt.so; if you don't patchelf that, (but instead patchelf other libraries, as I do here), you won't get this error. Note that librt.so has no RPATH prior to patchelf'ing. I suspect that the problem here is some corner case involving --set-rpath on a library that did not have one to begin with.

Expected behavior

The bootstrap completes.

patchelf --version output

# LD_LIBRARY_PATH=lib lib/ld.so.1 ./patchelf  --version
patchelf 0.14.5

Additional context

The last commit in the nixpkgs repo used above is just a bit of paranoia; you can drop that commit and you'll still get the same result.

I discussed this bug here but I'm no longer sure it is the same problem the person who opened that bug was having. In order to avoid hijacking their bug I am opening a separate one now that I have a simple way to reproduce the issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions