nix build --rebuild -f ./foo.nix pkgs.linux.collectd
error: unrecognised flag '--rebuild'

In reply to @fzakaria:matrix.org
Couldn't find the repository they contributed too.

In reply to @moritz.hedtke:matrix.org
"SUMMARY: AddressSanitizer: 6032 byte(s) leaked in 141 allocation(s)." - it's going down down down (just using GC for everything though)

In reply to @pamplemouss_:matrix.org
I would say that if you want to fuzz the parsing and evaluation logic, you should not use an in-process fuzzer.

I know that is the easy path but why take the easy path if you can take the hard path?

I assume you say that because it's extremely hard to do this in process because of the current memory management situation?

I think it's quite likely that I will soon go that route it's probably just way slower.

Also LLVM doesn't support out of process fuzzing does it? And the AFL ++ version is old in nixpkgs and a PITA to update

If by memory management, you mean the GC, then no, it's not because of that:
You can deactivate LeakSanitizer to stop complaining, and also manage the memory somewhat manually with an arena and deactivating the GC.

It's because some functions in nix manipulate a global state that cannot (i.e. that I could not) be reset to its initial state before the next run.
In process fuzzers run the harness in a loop, so the each run will "pollute" the subsequent one by mutating the state.

In reply to @fzakaria:matrix.org
I was thinking about trying out the different sanitizers on Nix for my compiler project (ASan, TSan etc..) -- and writing a report on the findings.
Has this already been done in Nix ?

In reply to @pamplemouss_:matrix.org
Also, LLVM support in-process fuzzing, and that's what I have been trying to use during the fellowship.
https://www.llvm.org/docs/LibFuzzer.html#introduction

In reply to @pamplemouss_:matrix.org
Kinda, as part of fuzzing. Also, I think there is an issue on the nix repo mentioning that idea.

In reply to @pamplemouss_:matrix.org

If by memory management, you mean the GC, then no, it's not because of that:
You can deactivate LeakSanitizer to stop complaining, and also manage the memory somewhat manually with an arena and deactivating the GC.

It's because some functions in nix manipulate a global state that cannot (i.e. that I could not) be reset to its initial state before the next run.
In process fuzzers run the harness in a loop, so the each run will "pollute" the subsequent one by mutating the state.

In reply to @pamplemouss_:matrix.org
Also, LLVM support in-process fuzzing, and that's what I have been trying to use during the fellowship. https://www.llvm.org/docs/LibFuzzer.html#introduction

In reply to @moritz.hedtke:matrix.org
I meant because some things are allocated by GC, some not and Nix is intentionally leaking data for efficiency. I want to first use the GC for everything also because I want to know whether this reduces memory usage in real use cases (maybe with some more code changes). But if I don't make progress I also thought about using an arena allocator as I read that in your post. That still wouldn't help with resetting globals would it? How did you solve that? On the other hand I think it's feasible to reset them