This is because C++ exceptions are very tricky, and most notably,
because a catch is run *after* things have been cleaned up, and we don't
*want* them cleaned up if we want usable stack traces.
$ nix nar
Lix crashed. This is a bug. We would appreciate if you report it along with what caused it at https://git.lix.systems/lix-project/lix/issues with the following information included:
Exception: std::runtime_error: lol
Stack trace:
0# nix::getStackTrace[abi:cxx11]() in /home/jade/lix/lix4/outputs/out/lib/liblixutil.so
1# 0x00007D58FC909292 in /home/jade/lix/lix4/outputs/out/lib/liblixmain.so
2# 0x00007D58FC49220A in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
3# 0x00007D58FC492275 in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
4# 0x00007D58FC4924C7 in /nix/store/ybjcla5bhj8g1y84998pn4a2drfxybkv-gcc-13.3.0-lib/lib/libstdc++.so.6
5# 0x00005B9799B45036 in nix
6# 0x00005B9799B3697F in nix
7# 0x00005B9799B3924D in nix
8# nix::handleExceptions(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::function<void ()>) in /home/jade/lix/lix4/outputs/out/lib/liblixmain.so
9# 0x00005B9799B38D2B in nix
10# 0x00007D58FC1E227E in /nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libc.so.6
11# __libc_start_main in /nix/store/wn7v2vhyyyi6clcyn0s9ixvl7d4d87ic-glibc-2.40-36/lib/libc.so.6
12# 0x00005B9799A7CF05 in nix
zsh: IOT instruction (core dumped) nix nar
Sadly our symbolizer sucks. But that's, well, improvable. The core dump
is at least much more useful now.
Obviously with async things being full of catch-alls, we have the same
problem. I think we might want to change those in another commit to only
catch nix::BaseError subclasses and let the rest fall into a noexcept
function so it will crash hard.
The daemon also could use this treatment, but I would like to be able to
send the client the crash message in phase 1 unwind. No idea how to
achieve that; all the ways I have seen are heinous.
Fixes: https://git.lix.systems/lix-project/lix/issues/698
Change-Id: I0b61f2e7a7003b92c39b1a0e90756979e5e59cb4
This is mostly to deal with fatal errors in NixOS tests, but it's useful
for all cases; assertion failures landing in syslog would be nice too,
but that's not as easy to do.
CC: https://git.lix.systems/lix-project/lix/issues/693
Change-Id: I6b5bd9800db3f5affe33f2946ea218e4a78f0c07
* changes:
fix: pre-build-hook did not run when useChroot == false
libstore/build: say what was failing when pre/post build hooks fail
daemon: complain much louder about unknown std::exception instances falling out
It turns out there is actually some history here.
Eight years ago, in 7f5b750b40, the
pre-build-hook condition got changed to check that useChroot is true
(which we will put down as "eelco making a mistake" because it makes no
sense) and that this->drv was a Derivation (as opposed to a
BasicDerivation as would be the case if the derivation was not present
on disk). The intent of this change was that pre-build-hook would not
run when the derivation doesn't exist, so that some hydras would not
explode.
However, this broke later when both cases became Derivation such that
AFAICT it will always run it if useChroot is true, which is absolutely
not the intended behaviour, but it is a reasonable interpretation as
well, just inconvenient for certain pre-build-hook usages.
So, I think the safest and most compatible behaviour is to run the
pre-build-hook but not guarantee that the derivation actually exists on
disk, since it already didn't run in many cases. Maybe the more correct
way is to actually write out the derivation if we are running a
pre-build-hook, but post-build-hook has exactly the same situation and
it's expected, so idk.
Fixes: https://git.lix.systems/lix-project/lix/issues/674
Change-Id: I75b828ae2a07ab373f44083507eb243459bd081d
These are only called when registering the schemes, so reordering them
to the previous order should ensure identical behaviour.
Change-Id: I12ea0e18e6dc897a91ad20cea3a765c0b96ae85e
Though this is a revert, it also involves fixing the code with new code
and a regression test. The problematic locking that was there before has
been removed, in any case.
This reverts commit ba728e46be.
Reason for revert: regression.
Fixes: https://git.lix.systems/lix-project/lix/issues/647
Change-Id: I326b1a10042ff69afbab38426e042e0dc2224a13
This merge commit returns to the previous state prior to the release but leaves the tag in the branch history.
Release created with releng/create_release.xsh
Change-Id: I4e4650d96de82b46c35171b3a9fc1e3a6ca8e6a1
We have obliterated the support across the build system for these
include paths anywhere, so the codemod is now redundant and can go.
Change-Id: I54082f39752c6aac6429e1c24026211adae8221a
This is a breaking change for non-migrated external clients. External
users always need to use <lix/libcmd/foo.hh> type include paths now.
This is as was always planned with the include rearrangement.
Change-Id: I269be91ff9f9cc94d5d3043cf3e0bdf8db1d8edb
This fixes a bug where flakes do not actually do purity path checks
correctly.
Tested-By: Jade Lovelace <lix@jade.fyi>
Change-Id: If7d131a8e73a5874fb15cfaa0dea3b8811ba35d2
This is a useful piece of functionality to being able to eat URL
hyperlinks, for instance, which is a bug that Lix has while dealing with
terminal output today.
Change-Id: I77b2de107b2525cad7ea5dea28bfba2cc78b9e6d
This commit makes Lix include the summarized content of the value being
indexed when it is bad.
lix/lix2 » nix eval --expr '{x.y = 2;}' 'x.y.z'
error: the value being indexed in the selection path 'x.y.z' at 'x.y' should be a set but is an integer: 2
lix/lix2 » nix eval --expr '{x.y = { a = 3; };}' 'x.y.z'
error: attribute 'z' in selection path 'x.y.z' not found inside path 'x.y', whose contents are: { a = 3; }
Did you mean a?
lix/lix2 » nix eval --expr '{x.y = { a = 3; };}' 'x.y.1'
error: the expression selected by the selection path 'x.y.1' should be a list but is a set: { a = 3; }
Change-Id: I3202aba0e437e00b4c6d3ee287a2d9a7c6892dbf
I want this for being able to write reasonable expect-test style tests
for oneliners. We will still probably want something like insta for more
complicated test cases where you actually *want* the output in a
different file, but for now this will do.
cc: https://git.lix.systems/lix-project/lix/issues/595
Change-Id: I6ddc42963cc49177762cfca206fe9a9efe1ae65d
I don't know what the heck the xonsh module is doing but its obviously
crimes so it has to go. It was never intended to be running here anyway.
Fixes: https://git.lix.systems/lix-project/lix/issues/593
Change-Id: I1877698469392f85884945aaa60987c68c4e0ebc
Lix requires a non-antiquated macOS SDK, and 24.11 does not yet have a
non-antiquated one as default.
Fixes: https://git.lix.systems/lix-project/lix/issues/588
Change-Id: Iad19c06d7fefe3a736cdcb39ced185e52dcfcbb8
Mostly these are bugprone-unused-local-non-trivial-variable.
Also fix instances of:
- bugprone-optional-value-conversion
- bugprone-inc-dec-in-conditions (please check this loop is correct, it
is the only non trivial code change in here)
- bugprone-unused-return-value (well, by fixing the lint config)
There are three notable changes relating to undefined vars:
- openLogFile ignoring the result. This is because openLogFile does a
whole bunch of mutation of member variables
- hiliteMatches: i am guessing this is because showing the derivation
name was unhelpful and it just got changed
- canonPath in NarAccessor: canonPath inside of a thing that is supposed
to be vfs based cannot possibly be correct, so let's delete it given
it is unused.
Fixes: https://git.lix.systems/lix-project/lix/issues/584
Change-Id: I887adc9ff28b61f726dcfed197e6796b414c2fcf
Calling a custom type size_t is incredibly sneaky and makes all the code
around this extremely context dependent.
Change-Id: Idae684781f45fe615020d8642f12a656ab2c15ad
Ever read gdb output and you just kinda get a headache because you have
to infer what a thread is by reading the stack trace? It's not hard, but
we could also just never have to do that again, which is also not hard.
Sample:
(gdb) info thr
Id Target Id Frame
* 1 LWP 3719283 "nix-daemon" 0x00007e558587da0f in accept ()
from target:/nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libc.so.6
2 LWP 3719284 "signal handler" 0x00007e55857b2bea in sigtimedwait ()
from target:/nix/store/c10zhkbp6jmyh0xc5kd123ga8yy2p4hk-glibc-2.39-52/lib/libc.so.6
The API design for this is forced by the macOS pthread_setname_np only
being able to change the current thread's name, but if we just conform
everything to that, it works everywhere.
Change-Id: I2b1d6ed41e3c94170cb0b4e73ad66f239ebd9c88
This allows <lix/*> includes to work from external projects not taking
Lix as a buildInput with Nix, but just using pkg-config.
Change-Id: I5b24fd0981344b013beaf406c16988dad17f0edb
These are still supported externally with pkg-config, but this commit
ensures they no longer build internally.
Change-Id: I2fa38f85e43b18f1f1dbcfdb0367de8f192aca2c
Context: we have include paths that are "types.hh" and similarly common
names. We currently have these compatibly available as
"lix/libutil/types.hh" externally but *not yet internally*. This is
because we don't have any way for the src directory to appear as
`"lix/"` from inside of Lix: the lix/ include directory is created by
the install process.
The goal of this whole thing is to make it clearer which component of
Lix that files are a part of, which should hopefully help at least a
little bit to new developers. One disadvantage of un-mixing these is
that it will cause some API changes if we ever move a file between
libraries, but that is not very common, and we don't care that much
about external API users.
This was planned for a while and is why we have a FixIncludes check to
begin with.
Personally I don't see a great benefit in rearranging our source code,
and in fact, it would probably be counterproductive:
- Moving the includes into a separate `include/` directory would just
make developers have to deal with more directories, when we can
already generate the desired layout through the build process.
- This would also decouple the .cc and .hh files which currently
conventionally have each others' definitions and declarations
respectively, right next to each other, making it easier for them to
feel decoupled and diverge.
Content: Add ../include as an include directory so that lix/ in include
paths will resolve to src/ within Lix itself, just as it does externally
today. This prepares for a further series of commits applying the actual
change to each library one-by-one by accepting both include versions at
once.
This could have been done with ../ and a symlink called lix, but we
would like to not accept libexpr/foo.hh internally for it would be
broken externally, so we need an otherwise empty directory for the
include.
Change-Id: Ideac17faadae2bcea2dffbab34eb27c582ede399
- Remove restrict-eval stuff that did nothing
- Remove builders stuff that appears unnecessary:
/* FIXME: The build hook in conjunction with import-from-derivation is
* causing "unexpected EOF" during eval */
settings.builders.setDefault("");
We removed that line and then observed that it works, so idk:
ifdtest.nix:
let
ifd = builtins.derivation {
name = "wat2";
builder = "/bin/sh";
args = [ "-c" "echo meow > $out" ];
system = "aarch64-linux";
};
in
builtins.readFile ifd
» NIX_CONFIG="builders = @/etc/nix/machines" build/src/nix-eval-jobs ifdtest.nix
warning: unknown setting 'trusted-users'
warning: `--gc-roots-dir' not specified
building '/nix/store/xxnd5rb49n3anyla5v71lgdk0wmhmijp-wat2.drv' on 'ssh-ng://root@voracle.jade.fyi'...
copying 0 paths...
building '/nix/store/xxnd5rb49n3anyla5v71lgdk0wmhmijp-wat2.drv'...
copying 1 paths...
copying path '/nix/store/h2yxq9lb7l0nd9plgqrcgf7nvsg67gl7-wat2' from 'ssh-ng://root@voracle.jade.fyi'...
- Changed the impure/flake code to override the pureEval setting, which
it was definitely *supposed* to be doing in the first place.
Daemon client handler processes are forked off of the main nix process
and thus will not have a signal handler thread anymore. This leads to a
high likelihood of bustage, since the Worker infrastructure expects the
interrupt infrastructure to actually, you know, work, to be able to get
interrupted.
The expected behaviour after fork is either:
- Start a signal handler thread if you expect to do complicated things
that need ReceiveInterrupts.
- Call restoreProcessContext and don't handle signals specially
otherwise.
Change-Id: I73d36b5bbf96dddd21d5e1c3bd0484d715c00e8b
This is done because the one in nixpkgs has several problems and we
don't want to conflict with them fixing those problems:
- not building shared libs
- not building debuginfo (more critical for us due to
https://git.lix.systems/lix-project/lix/issues/549)
- not setting the correct cmake build type
- not setting the correct cxxflags to build the coroutine library
- not building with clang (required for the coroutine library since gcc
is known to miscompile coroutines *in kj*).
CC: https://git.lix.systems/lix-project/lix/issues/551
Fixes: https://git.lix.systems/lix-project/lix/issues/550
Change-Id: Ia5b78dc1809963fdd1a8203b127a216cb575d751
This workaround was for the stdenv not being set when callPackage'ing
package.nix for some of the stranger CI outputs.
Change-Id: I2acdd6efa721b90dd3cb04358544d25d591ff084
This failed due to https://github.com/NixOS/nixpkgs/pull/346945, which
makes a second lowdown-unsandboxed that works in nix builds, and the
regular lowdown has executables that fail closed when the sandbox setup
fails.
The actual failure here is only visible on nixos-unstable at the moment,
not 24.05, but this commit should fix it up for all versions.
Fixes: https://git.lix.systems/lix-project/lix/issues/547
Change-Id: I50c0ecb59518ef01a7c0181114c1b4c5a7c6b78b
This was always a terrible idea independently of whether it crashes.
Stop doing it!
This commit was verified by running nix-shell on a trivial derivation
with --debug --verbose to get the vomit-level output of the shell rc
file and then diffing it before/after this change. I have reasonable
confidence it did not regress anything, though this code is genuinely
really hard to follow (which is a second reason that I split it into two
fmt calls).
Fixes: https://git.lix.systems/lix-project/lix/issues/533
Change-Id: I8e11ddbece2b12749fda13efe0b587a71b00bfe5
This change feels kind of gross and reveals a fair bit about the
disorganization of our tests, but I think it makes parts of it a bit
better.
Change-Id: Idb8d9a00cbd75d5c156678c6b408b42b59d5e4d7
So we received a report that the thread pool crashed due to an
Interrupted exception.
Relevant log tail:
copying path '/nix/store/0kal2k73inviikxv9f1ciaj39lkl9a87-etc-os-release' to 'ssh://192.168.0.27'...
Lix crashed. This is a bug. We would appreciate if you report it along with what caused it at https://git.lix.systems/lix-project/lix/issues with the following information included:
error (ignored): error: interrupted by the user
Exception: nix::Interrupted: error: interrupted by the user
Relevant stack trace:
4# __cxa_rethrow in /nix/store/22nxhmsfcv2q2rpkmfvzwg2w5z1l231z-gcc-13.3.0-lib/lib/libstdc++.so.6
5# nix::ignoreExceptionExceptInterrupt(nix::Verbosity) in /nix/store/ghxr2ykqc3rrfcy8rzdys0rzx9ah5fqj-lix-2.92.0-dev-pre20241005-ed9b7f4/lib/liblixutil.so
6# nix::ThreadPool::doWork(bool) in /nix/store/ghxr2ykqc3rrfcy8rzdys0rzx9ah5fqj-lix-2.92.0-dev-pre20241005-ed9b7f4/lib/liblixutil.so
7# 0x00007FA7A00E86D3 in /nix/store/22nxhmsfcv2q2rpkmfvzwg2w5z1l231z-gcc-13.3.0-lib/lib/libstdc++.so.6
8# 0x00007FA79FE99A42 in /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6
9# 0x00007FA79FF1905C in /nix/store/3dyw8dzj9ab4m8hv5dpyx7zii8d0w6fi-glibc-2.39-52/lib/libc.so.6
Notably, this is *not* in the main thread, so this implies that the
thread didn't get joined properly before their destructors got called.
That, in turn, should have only possibly happened because join() threw
on a previous iteration of the loop joining threads, I think. Or if it
threw while in the ThreadPool destructor. Either way we had better stop
letting Interrupted fall out of our child threads!
If:
- Interrupted was thrown inside the action in the main thread: it would
have fallen out of doWork if state->exception was already set and got
caught by ThreadPool::process, calling shutdown() and the join loop
which would crash the process entirely.
- Interrupted was thrown inside the action on a secondary thread: it
would have been caught and put into the exception field and then
possibly rethrown to fall out of the thread (since it was previously
ignoreExceptionExceptInterrupt).
The one possible hole in this hypothesis is that there is an "error
(ignored)" line in there implying that at least one Interrupted got
eaten by an ignoreExceptionInDestructor. It's also unclear whether this
got reordered because of stderr buffering.
Fixes: https://git.lix.systems/lix-project/lix/issues/542
Change-Id: I322cf050da660af78f5cb0e08ec6e6d27d09ac76
There is absolutely no good reason these should show up in NARs besides
misconfigured systems and as long as the case hack exists, unpacking
such a NAR will cause its repacking to be wrong on systems with case
hack enabled.
This should not have any security impact on Lix to fix, but it was one
of the vectors for CVE-2024-45593:
https://github.com/NixOS/nix/security/advisories/GHSA-h4vv-h3jq-v493
Change-Id: I85b6075aacc069ee7039240b0f525804a2d8edcb
This is capped at 12 because 3.7 seconds of startup is painful enough
and 5.5 seconds with 24 was more annoying.
Change-Id: I327db40fd98deaa5330cd9cf6de99fb07b2c1cb0
This also rewrites a lot of the command handling in the fixtures
library, since we want to more precisely control which way that the nix
store is set up in the tests, rather than the previous method of
renaming /nix/store to some temp dir (which allows builds but does not
allow any /nix/store paths or stability across runs, which is a
significant issue for snapshot testing).
It uses a builder to reduce the amount of state carelessly thrown
around.
The evil NARs are inspired by CVE-2024-45593
(https://github.com/NixOS/nix/security/advisories/GHSA-h4vv-h3jq-v493).
No bugs were found in this endeavor.
Change-Id: Iee41b055fa96529c5a3c761f680ed1d0667ba5da
I am tired of bad shell scripts, let me write bad python quickly
instead. It's definitely, $100%, better.
This is not planned as an immediate replacement of the old test suite,
but we::jade would not oppose tests getting ported.
What is here is a mere starting point and there is a lot more
functionality that we need.
Fixes: https://git.lix.systems/lix-project/lix/issues/488
Change-Id: If762efce69030bb667491b263b874c36024bf7b6
The test suite can load the global configuration files under certain
circumstances, and, though we would really rather it didn't ever do that
at all, we should at least break the mechanism.
Fixes: https://git.lix.systems/lix-project/lix/issues/474
Change-Id: Ib27cb43dd5dfaa70ac491c395b5ba308fd7bd289
