node-oom-heapdump
node-oom-heapdump copied to clipboard
blueconic
Build binaries for Alpine
Thank you. This is incomplete, because there are no alpine binaries for gcstats. I'm looking into that too, but it might take some time. And the original gcstats is not maintained, so we'll need to use an alternative fork, as proposed by @adnanraic. Will you consider that?
I'll think about that. Another way to go is to drop the need for gc-stats altogether, as it's only needed for
OOMImplementation: GC_MONITORING. We could release a new major version that only supports NATIVE_HOOK, making gc-stats no longer relevant.
Or you can change it to an optionalDependency (with proper protection on require), then I'll be able to install oom-heapdump without build tools, as long as I don't need gc monitoring.
Yes, that's possible as well. But it might be unexpected that GC_MONITORING won't work then, but that can be "solved" by logging a warning.
I did this 3 years ago, I no longer remember. :)
Just stumbled upon the repo on my disk and remembered.
Is this pr still relevant? E.g. Are prebuilt binaries still requested for alpine?
Looks like the existing binaries are linked with glibc, so it should be needed, yes.
@orgads it has been released to npm, can you check if this works for you?
hmm... Actually it looks like the original build works on alpine as well. I wonder how it works... 🤔
I guess you can revert the alpine parts of this change then. Sorry for the noise.
As long as you have the build tools in place, it will compile it from source indeed. Still, having the prebuilt binaries is still good to have, i'll leave it in for now.
I tested with 3.2.3 without installed build tools. I verified that the binary was not linked with musl, and that it was not built locally (the modification timestamp of the file was from a month ago).
It doesn't harm though, so it's your choice :)
Strange, how is it able to call into native code then? Or do you have oom monitoring disabled? Then it would indeed work without compilation.
No, it does use the native bindings.
Here:
docker run -w /app --rm -it node:18.19.0-alpine3.19 ash ✔ 1h 8m 53s orgads@siplenovo 20:27:58
/app # npm init -y
Wrote to /app/package.json:
[...]
/app # npm i [email protected]
[...]
/app # ls -l node_modules/node-oom-heapdump/build/Release/
total 28
-rwxr-xr-x 2 1001 127 23608 May 16 07:42 node_oom_heapdump_native.node
drwxr-xr-x 3 root root 4096 Jun 10 17:28 obj.target
/app # strings node_modules/node-oom-heapdump/build/Release/node_oom_heapdump_native.node | grep musl
/app # strings node_modules/node-oom-heapdump/build/Release/node_oom_heapdump_native.node | grep libc
libc.so.6
/app # cd node_modules/node-oom-heapdump/
/app/node_modules/node-oom-heapdump # ldd build/Release/node_oom_heapdump_native.node
/lib/ld-musl-x86_64.so.1 (0x7d307af48000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7d307aca9000)
libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7d307af48000) <--- This line is interesting :)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7d307ac85000)
Error relocating build/Release/node_oom_heapdump_native.node: _ZN2v86String11NewFromUtf8EPNS_7IsolateEPKcNS_13NewStringTypeEi: symbol not found
Error relocating build/Release/node_oom_heapdump_native.node: _ZN2v812api_internal12ToLocalEmptyEv: symbol not found
[...]
/app/node_modules/node-oom-heapdump # node
Welcome to Node.js v18.19.0.
Type ".help" for more information.
> require('bindings')('node_oom_heapdump_native.node')
{
call: [Function: call],
path: '/app/node_modules/node-oom-heapdump/build/Release/node_oom_heapdump_native.node'
}
This is what ChatGPT had to say about it: https://chatgpt.com/share/40b7f4f3-7bbf-406d-aef6-7375063f7107 :)
The bottom line is that it might be ok for simple API calls, but it is recommended to build separately for musl.
Thanks for the details, didn’t know how that worked n alpine. Let's keep it in for now :)