Updating to node 12.19.0 from 12.18.4 crashes my application

[special-character]

• 12.19.0:
• Darwin Brandons-MacBook-Pro.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64:

What steps will reproduce the bug?

I am not entirely sure what is using 12.19.0 but after updating from 12.18.4 my app crashes with the following error in node:

/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node[46808]: ../src/node_http_parser_impl.h:529:static void node::(anonymous namespace)::Parser::Initialize(const FunctionCallbackInfo<v8::Value> &): Assertion `args[3]->IsInt32()' failed.
 1: 0x1011f40c5 node::Abort() (.cold.1) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 2: 0x1000a5749 node::Abort() [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 3: 0x1000a55b1 node::Assert(node::AssertionInfo const&) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 4: 0x1000c6e1b node::(anonymous namespace)::Parser::Initialize(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 5: 0x100259838 v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 6: 0x100258df9 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 7: 0x100258562 v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]
 8: 0x100a02b19 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/brandonroberts/.nvm/versions/node/v12.19.0/bin/node]

How often does it reproduce? Is there a required condition?

This happens any time my app is started and a request is made.

Additional information

I tried to search for what is using the node_http_parser_impl in my application but there seems to be a good amount of possibilities (like express, fs-events, etc...). I am opening this because I think it is node related. Keeping my same node_modules and only switching from 12.18.4 to 12.19.0 causes the breakage.

[ronag]

I suspect you are using unidici somewhere in your dependencies. This was fixed in nodejs/undici#449 and released in 2.0.7.

[ronag]

@MylesBorins maybe we should add undici to CITGM?

[ChALkeR]

https://github.com/nodejs/undici/blob/master/lib/node/http-parser.js#L3-L4 — caused by using the internal API directly.
Usage of that API should be fixed in undici@2.0.7: nodejs/undici#448 (comment)

@special-character could you confirm that updating/resolving undici to 2.0.7 helps?

[ronag]

I think we can close this. Please let us know if there are any further questions.

[special-character]

Using 2.0.7 fixes the issue, thanks for the info!

[special-character]

I think I may have been incorrect about undici 2.0.7 fixing this issue. I am running into this again with:

node v12.19.0
undici v2.0.7

It is possible I though it was "working" because I use nvm and it switched to the default version I had set which worked fine.

[Flarna]

@special-character There may be other modules in the wild using the internal HTTPParser API which changed.
You could search for binding('http_parser') or binding("http_parser") in your node_modules folder to find who is actually loading it.

[ronag]

I think I may have been incorrect about undici 2.0.7 fixing this issue. I am running into this again with:

@special-character Do you have a repro?

[special-character]

I don't have a repro yet but can look into making a minimal one.

[ksharifbd]

I'm facing the same issue as described in #35582

Version: v16.0.0
Platform: Ubuntu 18.04 x86_64 kernel 4.15.0-142-generic

Update: There's already an issue filed here in this regard prisma/prisma#6684

[special-character]

Thanks @ksharifbd, I meant to follow up here. I didn't find out what the issue was but we are using prisma. We ended up jumping to node 14 which didn't have the problem.