nix-instantiate terminated by signal 11, --show-trace has no effect about nix

[edolstra]

A segfault in the evaluator is usually due to an infinite recursion in the Nix expression. GDB says:

#0  0x00007ffff7976505 in nix::ExprOpConcatLists::eval(nix::EvalState&, nix::Env&, nix::Value&) ()
   from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#1  0x00007ffff797e47d in nix::EvalState::forceValue(nix::Value&) () from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#2  0x00007ffff7976482 in nix::ExprVar::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#3  0x00007ffff7976523 in nix::ExprOpConcatLists::eval(nix::EvalState&, nix::Env&, nix::Value&) ()
   from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#4  0x00007ffff797e47d in nix::EvalState::forceValue(nix::Value&) () from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#5  0x00007ffff7976482 in nix::ExprVar::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
#6  0x00007ffff7976523 in nix::ExprOpConcatLists::eval(nix::EvalState&, nix::Env&, nix::Value&) ()
   from /nix/store/9n6swhw1qr71f8xls4i4dzfbmnachgv3-nix-1.1pre2718_8da6772/lib/nix/libexpr.so.0
...

repeated a few thousand times.

[kosmikus]

I've tested a bit, and I think it's not a bug in ghcWithPackages, but rather an actual problem in Nix. I've tried to add dependencies of hledgerWeb to the list instead of hledgerWeb itself, and it turns out that if I add both yesod and yesodDefault to the list, I get a segfault, but if I choose only one of the two, I don't.

[kosmikus]

It seems I can "fix" this by changing the definition of the library function closePropagation which is used by ghcWithPackages, so that it produces smaller intermediate lists while running. However, I think that only qualifies as a workaround. Nix shouldn't just segfault if something gets too large.

[peti]

How do we proceed with this issue? Would it be possible to commit the fix to closePropagation as a quick work around?

[edolstra]

@kosmikus, can you commit your fix? In general Nix expressions shouldn't recurse too deeply because the C stack is not infinite (well, not until we can use GCC's -fsplit-stack). The crashNix expression goes over 80000 levels deep.

It would be nice to give a better error message than "signal 11", but there is no portable way to detect a stack overflow.

[kosmikus]

I had hesitated committing the fix because these are central library functions which may affect other things, and I haven't checked if my new version returns all results in the same order. But yes, I can try to do it.

[kosmikus]

Committed as NixOS/nixpkgs@3fbd694.

[peti]

The crashes in ghcWithPackages are now gone.