-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory corruption #4200
Comments
I guess I’ll just leave it bisecting overnight. So far, if I did not mess up, I know that:
|
Current status:
The next step is |
If I skip it, the next step |
(“skip” means that it either does not build or hangs during evaluation) |
That would be #4030 (cc @roberth @Ericson2314 @edolstra). |
Ok, after reading the PR I see why it hangs... I guess, I’d need to bisect it with some specific version of |
Actually, I double-checked manually and it looks like all those skips are compilation failures, not freezes. And the commit it points to fails for a different reason, ugh. |
So, here is the latest run:
I believe, this time it’s correct and basically what it says is that the issue is somewhere in that PR, but since it all either doesn’t compile or crashes with protocol errors, it’s hard to say where exactly the specific memory corruption was introduced. |
Seems related to #4178. With master and an unmodified https://github.com/serokell/nix-malloc-repro I get
After fixing the trace messages it hangs while draining the source ( EDIT: not an infinite recursion because the process is idle. |
The PR iterates on the protocol itself, so intermediate versions are only compatible with a daemon built from the exact same commit. |
I see, it makes sense. Well, if I remember correctly, only the very last skip is due to a protocol error, all others are compilation errors. I think what we can do is try that last commit in single-user mode, although I’m not sure if it will provide any useful information. |
Crucially this introduces BoehmGCStackAllocator, but it also adds a bunch of wiring to avoid making libutil depend on bdw-gc. Part of the solutions for NixOS#4178, NixOS#4200
#4206 fixes the memory corruption, but I also had to increase the stack size and |
#4207 takes care of the |
Toady involving a stack.yaml with haskell.nix as well, I observe: nix develop
warning: Git tree '/home/blaggacao/ghq/git.joeyh.name/git/arduino-copilot' is dirty
trace: gitSource.nix: /nix/store/mzqnhviawcj3lhdimjybj776177h7dzx-source does not seem to be a git repository,
assuming it is a clean checkout.
trace: To make project.stack-nix for arduino-copilot a fixed-output derivation but not materialized, set `stack-sha256` to the output of the 'calculateMaterializedSha' script in 'passthru'.
trace: To materialize project.stack-nix for arduino-copilot entirely, pass a writable path as the `materialized` argument and run the 'updateMaterialized' script in 'passthru'.
malloc(): invalid next size (unsorted)
[1] 1366203 abort (core dumped) nix develop on nix --version
nix (Nix) 3.0pre20200829_f156513 Is this closeable and I need to update my nix version? (EDIT: I think I get the clue now: |
I confirm it does not happen any more with: nix --version
nix (Nix) 2.4pre20201201_5a6ddb3 → close? |
I marked this as stale due to inactivity. → More info |
Describe the bug
When trying to build a certain expression, I am getting:
or, sometimes, much less often either:
or
or some other
malloc
error, which I failed to write down.There seems to be something interesting going on with string allocation.
Steps To Reproduce
I managed to minimise our case to a simple build with
haskell.nix
of an empty pseudo-Haskell project with a long enoughstack.yaml
file. By varying the size ofstack.yaml
you can get different errors and have fun (🥳).Unfortunately, since it uses
haskell.nix
, you might need to setup the IOHK binary cache. Or maybe not, I’m not sure... maybe we can share our cache...git clone https://github.com/serokell/nix-malloc-repro.git
cd nix-malloc-repro
nix build -f .
Note that both
nix-build
andnix-daemon
dump core.Expected behavior
Some error related to the Haskell project being completely empty.
Additional context
The repository has its own pinned dependencies and I am using
nixUnstable
from thenixos-20.09
branch, although I don’t think any of this matters.master
(e0ca98c).The text was updated successfully, but these errors were encountered: