test: fix flaky async-hooks/test-zlib.zlib-binding.deflate

[addaleax]

Previously, the typed arrays used in this test would not
automatically be kept alive by the native handle when
it’s using them, so the V8 garbage collector could collect
them while they are still in use by the zlib module,
leading to memory corruption.

Fixes: #20907

Fyi @apapirovski@joyeecheung@Trott@Fishrock123@BridgeAR@mcollina ;)

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[addaleax]

CI: https://ci.nodejs.org/job/node-test-commit/18918/
LinuxOne Stress test CI [scheduled]: https://ci.nodejs.org/job/node-stress-single-test/1891/

[apapirovski]

😅 I love that this is the fix.

[Fishrock123]

Hah, unbelievable. What a debug story this was.

https://twitter.com/addaleax/status/1002279690445484033

[mcollina]

LGTM

[addaleax]

Might want to fast-track this? Feel free to 👍 this comment if you think so

[hashseed]

For posterity, do you mind adding a more detailed explanation to this? Including what you used to debug?

[addaleax]

@hashseed Thanks for the reminder :) I’ve updated the PR description/commit message a bit, let me know how that sounds to you

[apapirovski]

@addaleax I'm super happy with the commit message on my end for sure but if you don't mind explaining how you finally found it / got it to fail with valgrind, I think that would be really great? Just for the closure for all of us who observed... 😄

[hashseed]

Tbh I don't actually see why this test fails. I can only guess that the zlib binding somehow doesn't keep the backing store of the incoming buffer around, but does the correct thing if the argument is a TypedArray? That sounds like a bug in zlib to me though.

[addaleax]

@hashseed It doesn’t keep the backing store around either way, and relies on the JS side of things to do that (but this test didn’t do that before). It doesn’t really treat Buffers different from other kinds of TypedArrays…

I assume the intention for that original behaviour here was not having to track more Persistents in C++ land. I have no idea whether that’s reasonable or not, tbh.

[joyeecheung]

Thanks for all the work that went into this!

(We have something similar to this fix in fs.write, this pattern just looks like a footgun to me...can we do something about this? Refactor how the bindings write stuff?)

[addaleax]

@apapirovski I don’t really know either! It just Worked™ once when running it with valgrind and redirecting output to a file, it contained a pretty good indication of this use-after-free behaviour…

[hashseed]

Oh I see.

So the issue is that Init takes a Uint32Array, but only keeps a raw uint32_t pointer to the backing store. Even when the backing store doesn't move, it may still be collected if the Uint32Array dies. That then may or may not cause a segfault, depending on whether the OS has unmapped the backing memory area.

Can we expect users to know about this detail or can we expect actual uses of this API to always use the write result, so we would not run into this issue in the wild?

[apapirovski]

Can we expect users to know about this detail or can we expect actual uses of this API to always use the write result, so we would not run into this issue in the wild?

This tests internals, our zlib code actually doesn't behave in this way so it was just a flawed implementation of the C++ binding.

(This test is specifically for the async hooks in relation to the binding hence using it directly.)

[Trott]

Sole CI failure is a known-flaky being worked on.

Re-run: https://ci.nodejs.org/job/node-test-commit-linux-containered/4864/

[Trott]

Containered re-run again: https://ci.nodejs.org/job/node-test-commit-linux-containered/4870/

[addaleax]

Landed in 2efe4c2