If it was out of memory it would have to be using a lot of memory to be reproducible on my desktop machine.

Good point, I have 64GB and was reproducing the issue fairly regularly. I take it there's no artificial memory limit from dotnet or the build sandbox?

Maybe it's hitting a file handle ulimit or something?

Could be something like that. Or could just be random segfaults in buggy software... 🤔

It would be nice to know more about the child process invocation (args, output, exit code).

Anything specific you want me to test, other than just time -v?

I'm wondering if it is practical to move the tests into a passthru.tests derivation 🤔

That way 1) end-users wouldn't need to run the tests to build the unfree package, 2) intermittent tests wouldn't cause build failures on hydra.

I'd still like to uncover the actual issue, but I'm curious if extracting the tests to a separate derivation is possible?

I guess the test derivation would need the same src as the main package, to access the test cases and relevant build properties. It'd also need the main package as an input, to get the built binaries.

That sounds reasonable, but what I'm unsure of is how easy it'd be to tell dotnet test to run the local test cases against the pre-built binaries from the main package?

Maybe I'll see if I can find anything useful in VSTestTask

Looks like the impl is here: https://github.com/dotnet/dotnet/blob/main/src/vstest/src/Microsoft.TestPlatform.Build/Tasks/VSTestTask.cs

There's a note about the "Task returned false but did not log an error." error at line 69.

Other than that, I nothing is jumping out at me 🤔

Also: I noticed that the Test host process crashed and "VSTestTask" task returned false but did not log an error. errors also appear in normal (failing) build logs, even without -v:diag. We just need to scroll up to find them, as they're usually not at the end of the logs.

In reply to @mattsturg:matrix.org

I'm wondering if it is practical to move the tests into a passthru.tests derivation 🤔

That way 1) end-users wouldn't need to run the tests to build the unfree package, 2) intermittent tests wouldn't cause build failures on hydra.

I'd still like to uncover the actual issue, but I'm curious if extracting the tests to a separate derivation is possible?

I guess the test derivation would need the same src as the main package, to access the test cases and relevant build properties. It'd also need the main package as an input, to get the built binaries.

That sounds reasonable, but what I'm unsure of is how easy it'd be to tell dotnet test to run the local test cases against the pre-built binaries from the main package?

One way to do this would be to disable tests and just put an override with them enabled in passthru.tests.

Is it consistently crashing in certain tests? Maybe we can get away with disabling only certain tests or projects?

One way to do this would be to disable tests and just put an override with them enabled in passthru.tests.

Good idea. I've opened https://github.com/NixOS/nixpkgs/pull/421459

Overriding is a simple solution, but it means building the app twice... I was hoping we'd be able to reuse the binaries from the main package, as an input for the test package.

Is it consistently crashing in certain tests? Maybe we can get away with disabling only certain tests or projects?

I'm not sure; I don't think it prints which test failed in the logs. It might be hidden in the v:diag logs somewhere though. I also suspect it is a specific test or project, so if we can identify it we can disable it and report the issue upstream.

Due to this, i mean.

Overriding nugetDeps is just one example that caused issue. For example overriding projectFile wouldn't work either...