resolve-system-dependencies.pl hanging

[kirelagin]

This is OS X 10.11.5.

› rm /nix/var/nix/dependency-maps/x86_64-Darwin-15.5.0.map
› nix-env --option use-binary-caches false -iA nixpkgs.hello
installing ‘hello-2.10’
these derivations will be built:
  /nix/store/ww4k3h185z98n1xqh3izx9a1da950dqa-hello-2.10.tar.gz.drv
  /nix/store/x5dj533g2wx8c64l6kx67ic4yd8x22q3-hello-2.10.drv
building path(s) ‘/nix/store/3x7dwzq014bblazs7kq20p9hyzz0qh8g-hello-2.10.tar.gz’
Finding dependencies for /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation...
^C|   killing process 13685
error: interrupted by the user

The problem is here. It totally seems to me that otool is not willing to output anything unless someone is actually reading its output. If I execute that same otool command line myself, everything works fine; but if I run resolve-system-dependencies.pl the otool process hangs.

I’m as far from being a Perl guru as it gets, so I made a quick and dirty adjustment: I made it first read all the output and only then waitpid and check the exit status. (Not showing the code here as it is extremely ugly.) This helped.

[kirelagin]

Actually, to put it into more technical terms, I believe that the output of otool is large enough to overfill the buffer and thus it blocks. So now, after thinking about it, I believe that it is indeed very wrong to waitpid before reading all of the output. I just need to figure out how to write this in Perl.

[kirelagin]

Here is an attempt, using best of my (non-existent) Perl knowledge.

[kirelagin]

@domenkozar install bug?

[kirelagin]

Looks like this was some weirdness on the side of the OS. After a reboot the issue (and a few others) is gone. But I think, this changes make sense anyway.

[domenkozar]

I'm labeling all issues that rise when Nix is being installed or is installing. These should have a priority.

[chris-martin]

What's the workaround until this gets merged? How do I apply this patch?

This is a big blocker. It's seeming to me that Nix just doesn't work at all on OSX because of it?

[kirelagin]

@chris-martin Actually in my case the workaround was to restart the computer. Apparently, such a small buffer is not a normal thing, but for some reason it suddenly became small, probably due to a bug in OS X or whatever. Restarting the OS made the issue go away.

[domenkozar]

See #1030

[chris-martin]

fwiw, a reboot did work for us (thanks @kirelagin 👍)

[domenkozar]

Closing due to #1030 (comment)