modules: adding load linked modules feature by thlorenz · Pull Request #8 · nodejs/node

thlorenz · 2014-11-28T18:30:11Z

introduced NM_F_LINKED flag to identify linked modules
setting node_is_initialized after calling V8::Initialize in order to
make the right decision during initial module registration
introduced modlist_linked in order to track modules that were
pre-registered in order to complete it once node is initialized
completing registration of linked module similarly to the way it's
done inside DLOpen

- introduced NM_F_LINKED flag to identify linked modules - setting node_is_initialized after calling V8::Initialize in order to make the right decision during initial module registration - introduced modlist_linked in order to track modules that were pre-registered in order to complete it once node is initialized - completing registration of linked module similarly to the way it's done inside DLOpen

bnoordhuis · 2014-11-28T18:33:02Z

For the record, I already LGTM'd this but I'd like @trevnorris to sign off on it.

trevnorris · 2014-12-01T22:11:23Z

LGTM

rvagg · 2014-12-01T22:43:39Z

running full CI on this https://jenkins-node-forward.nodesource.com/job/iojs+any-pr+multi/3/

rvagg · 2014-12-01T22:45:07Z

@thlorenz would it be difficult to add a simple test for this in test/addons/ and perhaps a super-simple sanity check in test/simple/? seems like something that's ripe for regressions.

thlorenz · 2014-12-01T23:12:44Z

Ideally yes, but that would require adding something to node.gyp the way nad does.
That would also mean we'd have to recompile to run it.

So I think it'd have to be some integration test, possibly even executed manually, not sure.

Not sure when I can get to it. Could we merge this anyhow and I'll think about how to best do this and supply tests in another PR?

trevnorris · 2014-12-03T01:18:34Z

I'd normally require a test, but since the API is technically "private" (done, IMO, so the API can be hashed out as it's used if necessary) there's no need for a test at the moment.

thlorenz · 2014-12-03T01:38:49Z

Thanks @trevnorris and as I said it won't be a simple test.
Will hash out with @rvagg how to best include and run these integrationy tests in general and add one for this at that point.

rvagg · 2014-12-03T03:01:09Z

@thlorenz I assumed that the test/addons/ directory would be the place for this--they are a separate test run and are all compiled and loaded to test, perhaps we could do something similar to make this testable?

thlorenz · 2014-12-03T09:32:11Z

No this doesn't work exactly like an addon. It's a linked module, i.e. it has to be made part of the code base by modifying the node.gyp file (what nad does).

rvagg · 2014-12-04T00:25:58Z

this got landed in joyent/node didn't it? should we land it here or close and wait for the next pull from joyent/node?

thlorenz · 2014-12-04T05:55:28Z

It did land in joyent/node as well but in different shape since things were adapted to older API, i.e. env->SET_MODULE was not available there.

- introduced NM_F_LINKED flag to identify linked modules - setting node_is_initialized after calling V8::Initialize in order to make the right decision during initial module registration - introduced modlist_linked in order to track modules that were pre-registered in order to complete it once node is initialized - completing registration of linked module similarly to the way it's done inside DLOpen PR-URL: #8 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

rvagg · 2014-12-04T08:54:46Z

landed via f4e058d

- introduced NM_F_LINKED flag to identify linked modules - setting node_is_initialized after calling V8::Initialize in order to make the right decision during initial module registration - introduced modlist_linked in order to track modules that were pre-registered in order to complete it once node is initialized - completing registration of linked module similarly to the way it's done inside DLOpen PR-URL: #8 Reviewed-by: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>

Original commit message: Merged: [compiler] Fix bug in SimplifiedLowering's overflow computation Revision: e371325bcb03f20a362ebfa48225159702c6fde7 BUG=chromium:1126249 NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true R=tebbi@chromium.org Change-Id: I411d9233f77992e73da12784cef59c885999b556 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415988 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/branch-heads/8.6@{#8} Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1} Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472} Refs: v8/v8@a59e3ac

Original commit message: Merged: [compiler] Fix bug in SimplifiedLowering's overflow computation Revision: e371325bcb03f20a362ebfa48225159702c6fde7 BUG=chromium:1126249 NOTRY=true NOPRESUBMIT=true NOTREECHECKS=true R=tebbi@chromium.org Change-Id: I411d9233f77992e73da12784cef59c885999b556 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2415988 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/branch-heads/8.6@{#8} Cr-Branched-From: a64aed2333abf49e494d2a5ce24bbd14fff19f60-refs/heads/8.6.395@{#1} Cr-Branched-From: a626bc036236c9bf92ac7b87dc40c9e538b087e3-refs/heads/master@{#69472} Refs: v8/v8@a59e3ac PR-URL: #38275 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Jiawen Geng <technicalcute@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com>

Update README for v18.12.1

This function call can fail with `Z_VERSION_ERROR` if the compiled library vs loaded library mismatched in version number or in stream structure size. In those cases, zlib doesn't initialize the `strm_.msg` field to null. Therefore, when a `CompressionError` object is created via `ErrorForMessage()`, it can read a stale or uninitialized `strm_.msg` pointer that will cause a crash. Example ASAN report: ``` AddressSanitizer: SEGV on unknown address #0 __strlen_avx2 string/../sysdeps/x86_64/multiarch/strlen-avx2.S:76 nodejs#1 strlen (/work/node/out/Debug/node+0x1a42ab7) nodejs#2 v8::(anonymous namespace)::StringLength(char const*) /work/node/out/../deps/v8/src/api/api.cc:7581:16 nodejs#3 v8::(anonymous namespace)::StringLength(unsigned char const*) /work/node/out/../deps/v8/src/api/api.cc:7587:10 nodejs#4 v8::String::NewFromOneByte(v8::Isolate*, unsigned char const*, v8::NewStringType, int) /work/node/out/../deps/v8/src/api/api.cc:7677:3 nodejs#5 node::OneByteString(v8::Isolate*, char const*, int, v8::NewStringType) /work/node/out/../src/util-inl.h:166:10 nodejs#6 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::EmitError(node::(anonymous namespace) ::CompressionError const&) /work/node/out/../src/node_zlib.cc:565:7 nodejs#7 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::CheckError() /work/node/out/../src/node_zlib.cc:519:5 nodejs#8 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::AfterThreadPoolWork(int) /work/node/out/../src/node_zlib.cc:543:10 nodejs#9 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::operator()(uv_work_s*, int) const /work/node/out/../src/threadpoolwork-inl.h:57:15 nodejs#10 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::__invoke(uv_work_s*, int) /work/node/out/../src/threadpoolwork-inl.h:48:7 nodejs#11 uv__work_done /work/libuv-1.51.0/src/threadpool.c:330:5 nodejs#12 uv__async_io.part.0 /work/libuv-1.51.0/src/unix/async.c:208:5 ``` Signed-off-by: ndossche <nora.dossche@ugent.be>

This function call can fail with `Z_VERSION_ERROR` if the compiled library vs loaded library mismatched in version number or in stream structure size. In those cases, zlib doesn't initialize the `strm_.msg` field to null. Therefore, when a `CompressionError` object is created via `ErrorForMessage()`, it can read a stale or uninitialized `strm_.msg` pointer that will cause a crash. Example ASAN report: ``` AddressSanitizer: SEGV on unknown address #0 __strlen_avx2 string/../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 strlen (/work/node/out/Debug/node+0x1a42ab7) #2 v8::(anonymous namespace)::StringLength(char const*) /work/node/out/../deps/v8/src/api/api.cc:7581:16 #3 v8::(anonymous namespace)::StringLength(unsigned char const*) /work/node/out/../deps/v8/src/api/api.cc:7587:10 #4 v8::String::NewFromOneByte(v8::Isolate*, unsigned char const*, v8::NewStringType, int) /work/node/out/../deps/v8/src/api/api.cc:7677:3 #5 node::OneByteString(v8::Isolate*, char const*, int, v8::NewStringType) /work/node/out/../src/util-inl.h:166:10 #6 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::EmitError(node::(anonymous namespace) ::CompressionError const&) /work/node/out/../src/node_zlib.cc:565:7 #7 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::CheckError() /work/node/out/../src/node_zlib.cc:519:5 #8 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::AfterThreadPoolWork(int) /work/node/out/../src/node_zlib.cc:543:10 #9 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::operator()(uv_work_s*, int) const /work/node/out/../src/threadpoolwork-inl.h:57:15 #10 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::__invoke(uv_work_s*, int) /work/node/out/../src/threadpoolwork-inl.h:48:7 #11 uv__work_done /work/libuv-1.51.0/src/threadpool.c:330:5 #12 uv__async_io.part.0 /work/libuv-1.51.0/src/unix/async.c:208:5 ``` Signed-off-by: ndossche <nora.dossche@ugent.be> PR-URL: #63476 Reviewed-By: Anna Henningsen <anna@addaleax.net>

…m, wrong offsets fail silently. affects every milo user of the feature, not just this port: compiler takes the layout on faith, a wrong field reads a neighbouring one and returns plausible garbage w/ no error. workaround (c _Static_assert) needs a c file most pure-milo users don't have. ranked fixes: docs -> #[c_layout] compiler-emitted guards (~1-2d, 90% of safety) -> @cImport (weeks). also note the same faith applies to 341 hand-written extern fn decls, and that unsafe deliberately doesn't cover either (tracks provenance, not layout/effects). mark nodejs#3 unsafe-lint resolved+shipped

This function call can fail with `Z_VERSION_ERROR` if the compiled library vs loaded library mismatched in version number or in stream structure size. In those cases, zlib doesn't initialize the `strm_.msg` field to null. Therefore, when a `CompressionError` object is created via `ErrorForMessage()`, it can read a stale or uninitialized `strm_.msg` pointer that will cause a crash. Example ASAN report: ``` AddressSanitizer: SEGV on unknown address #0 __strlen_avx2 string/../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #1 strlen (/work/node/out/Debug/node+0x1a42ab7) #2 v8::(anonymous namespace)::StringLength(char const*) /work/node/out/../deps/v8/src/api/api.cc:7581:16 #3 v8::(anonymous namespace)::StringLength(unsigned char const*) /work/node/out/../deps/v8/src/api/api.cc:7587:10 #4 v8::String::NewFromOneByte(v8::Isolate*, unsigned char const*, v8::NewStringType, int) /work/node/out/../deps/v8/src/api/api.cc:7677:3 #5 node::OneByteString(v8::Isolate*, char const*, int, v8::NewStringType) /work/node/out/../src/util-inl.h:166:10 #6 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::EmitError(node::(anonymous namespace) ::CompressionError const&) /work/node/out/../src/node_zlib.cc:565:7 #7 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::CheckError() /work/node/out/../src/node_zlib.cc:519:5 #8 node::(anonymous namespace)::CompressionStream< node::(anonymous namespace)::ZlibContext> ::AfterThreadPoolWork(int) /work/node/out/../src/node_zlib.cc:543:10 #9 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::operator()(uv_work_s*, int) const /work/node/out/../src/threadpoolwork-inl.h:57:15 #10 node::ThreadPoolWork::ScheduleWork() ::'lambda'(uv_work_s*, int) ::__invoke(uv_work_s*, int) /work/node/out/../src/threadpoolwork-inl.h:48:7 #11 uv__work_done /work/libuv-1.51.0/src/threadpool.c:330:5 #12 uv__async_io.part.0 /work/libuv-1.51.0/src/unix/async.c:208:5 ``` Signed-off-by: ndossche <nora.dossche@ugent.be> PR-URL: #63476 Reviewed-By: Anna Henningsen <anna@addaleax.net>

rvagg closed this Dec 4, 2014

rvagg mentioned this pull request Jan 3, 2015
governance: Add new Collaborators #234
Closed

kvic-z mentioned this pull request Oct 27, 2015
compile error ,target=arm7 #3224
Closed

jianpingw mentioned this pull request Dec 13, 2015
node js 5.2.0 segmentation fault after console.log #4261
Closed

dmitryame mentioned this pull request Mar 10, 2016
Abort trap: 6 #5646
Closed

rupamkhaitan mentioned this pull request Jun 27, 2016
trap invalid opcode ip:fea6f9 #3898
Closed

mhhf mentioned this pull request Aug 24, 2016
Assertion failed ../deps/uv/src/unix/stream.c, line 1563 #8258
Closed

rdkgit mentioned this pull request Nov 11, 2016
SSL core dump in v6.9.1 #9551
Closed

shyhpei mentioned this pull request Feb 3, 2017
segmentation fault at v8::internal::StoreBuffer::EnsureSpace () #11156
Closed

sxa mentioned this pull request Mar 16, 2017
npm --version segfaults on v7.7.3 linux ppc64 (BE) only ON RHEL 7 #11882
Closed

myitcv mentioned this pull request Aug 1, 2017
Segfault in v8.2.1 #14567
Closed

lolobug mentioned this pull request Oct 31, 2018
fatal v8 error:Entering the V8 API without proper locking in place #23997
Closed

This was referenced Jun 28, 2020
There appears to be a bug with the http2 header decoding #28632
Closed
const dummy = new ArrayBuffer(); RangeError at v8.js #31370
Closed

KungFuJesus mentioned this pull request Jul 10, 2020
build 12.13.0 on mips64el segfault around mksnapshot #30304
Closed

gengjiawen mentioned this pull request Aug 12, 2020
N-API reference management leaks memory #34731
Closed

Flarna mentioned this pull request Aug 14, 2020
[v12.x backport] deps: V8: cherry-pick eec10a2fd8fa and #34008 #34776
Closed

FlorSanders mentioned this pull request Aug 19, 2020
Raspberry Pi OS, malloc() when running script #34828
Closed

silverwind mentioned this pull request Aug 20, 2020
https/http2: random crashes on macOS with simple server #34854
Closed

dislon mentioned this pull request Sep 4, 2020
Debugger crashes with assertion failure while using Chrome DevTools and remote debug #17259
Open

tnodejs mentioned this pull request Mar 25, 2021
use node 12.9.0 cause carsh problem #37902
Closed

alvin-7 mentioned this pull request Dec 15, 2021
create coredump with running in inspect #41178
Closed

mhdawson mentioned this pull request Sep 26, 2022
node-api: generalize finalizer second pass callback #44141
Closed

theanarkh mentioned this pull request Oct 18, 2022
crash when trace ic stats #45052
Closed

khagankhan mentioned this pull request Oct 13, 2023
Use of Uninitialized Memory Detected in bytecode_builtins_list_generator by MemorySanitizer #50171
Closed

dumganhar pushed a commit to dumganhar/node that referenced this pull request Dec 17, 2024
Merge pull requestnodejs#8from nodegui/update_readme
90f6577
Update README for v18.12.1

This comment was marked as off-topic.
Sign in to view

ronking-zhu mentioned this pull request Oct 13, 2025
Nodejs official released build has conflict with msodbcsql driver due to incompatible openssl version #60240
Closed

sadan4 mentioned this pull request Nov 5, 2025
NodeJS segfaults when trying to debug this code #60580
Closed

jackzhp mentioned this pull request Nov 5, 2025
Large file download (above 50MB, without "range processing") results in HTTP2_PROTOCOL_ERROR in Chrome #59465
Closed

guybedford mentioned this pull request Apr 17, 2026
[v22.x] deps: V8: backport Wasm exception handling correctness fixes #62783
Closed

Uh oh!

Uh oh!

Conversation

thlorenz commented Nov 28, 2014

Uh oh!

bnoordhuis commented Nov 28, 2014

Uh oh!

trevnorris commented Dec 1, 2014

Uh oh!

rvagg commented Dec 1, 2014

Uh oh!

rvagg commented Dec 1, 2014

Uh oh!

thlorenz commented Dec 1, 2014

Uh oh!

trevnorris commented Dec 3, 2014

Uh oh!

thlorenz commented Dec 3, 2014

Uh oh!

rvagg commented Dec 3, 2014

Uh oh!

thlorenz commented Dec 3, 2014

Uh oh!

rvagg commented Dec 4, 2014

Uh oh!

thlorenz commented Dec 4, 2014

Uh oh!

rvagg commented Dec 4, 2014

Uh oh!

This comment was marked as off-topic.

This comment was marked as off-topic.

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants