Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Check failed: result.second" in Node 14.1 via Sharp 0.24 #2196

Closed
asilvas opened this issue May 6, 2020 · 8 comments
Closed

"Check failed: result.second" in Node 14.1 via Sharp 0.24 #2196

asilvas opened this issue May 6, 2020 · 8 comments

Comments

@asilvas
Copy link

asilvas commented May 6, 2020

Not sure if this has been resolved in Sharp 0.25+, but wanted to make aware this is apparently a breaking change in node. nodejs/node#32463 nodejs/node#31061

#FailureMessasge Object: 0x7ffcd838ca70
#
#
#
# Check failed: result.second.
# Fatal error in , line 0

Are you able to provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem? Not at this time as it was only reproducible in production so it had to be rolled back quickly.

Are you able to provide a sample image that helps explain the problem? Not at this time. Will investigate further.

What is the output of running npx envinfo --binaries --system? Don't have since was forced to do fast rollback.

Will update if I'm able to reproduce outside of production environment.

@asilvas asilvas added the triage label May 6, 2020
@lovell
Copy link
Owner

lovell commented May 6, 2020

Thanks for the notification Aaron, I wasn't aware of this.

Based on those discussions I would guess many native addons are going to break with Node.js 14, even those using N-API, as sharp v0.25.0+ does.

Comments on the original PR at nodejs/node#30782 also suggest N-API won't protect against this.

It's unclear to me right now exactly how to work around this, e.g. copying memory before creating a Buffer to ensure every Buffer has a unique location will have performance implications.

@lovell
Copy link
Owner

lovell commented May 8, 2020

If you're able to provide some code to reproduce this that would be very useful as I've not yet been able to do so.

The metadata() function uses Napi::Buffer<char>::New(...) fairly extensively to convert EXIF, IPTC, XMP and other metadata into Buffer instances so that would be my best guess as to where this might be occurring.

@asilvas
Copy link
Author

asilvas commented May 8, 2020

So far I've only seen it on alpine. Hopefully I'll have repro script soon.

@asilvas
Copy link
Author

asilvas commented May 8, 2020

Was finally able to repro on Mac, but it takes quite a while. Current code is quite complex, so will take some time to narrow down to minimal repro.

#
# Fatal error in , line 0
# Check failed: result.second.
#
#
#
#FailureMessage Object: 0x7ffeefbf6600
 1: 0x100102862 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 2: 0x100f6e6b3 V8_Fatal(char const*, ...) [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 3: 0x10049b85d v8::internal::GlobalBackingStoreRegistry::Register(std::__1::shared_ptr<v8::internal::BackingStore>) [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 4: 0x1001e8a96 v8::ArrayBuffer::GetBackingStore() [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 5: 0x10007a7f0 node::Buffer::New(node::Environment*, char*, unsigned long, void (*)(char*, void*), void*) [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 6: 0x10007a54a node::Buffer::New(v8::Isolate*, char*, unsigned long, void (*)(char*, void*), void*) [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
 7: 0x10585f4a4 PipelineWorker::HandleOKCallback() [/Users/asilvas/image-api/node_modules/sharp/build/Release/sharp.node]
 8: 0x1058455c6 Nan::AsyncWorker::WorkComplete() [/Users/asilvas/image-api/node_modules/sharp/build/Release/sharp.node]
 9: 0x105845122 Nan::AsyncExecuteComplete(uv_work_s*) [/Users/asilvas/image-api/node_modules/sharp/build/Release/sharp.node]
10: 0x10095db08 uv__work_done [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
11: 0x1009629d4 uv__async_io [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
12: 0x100975dca uv__io_poll [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
13: 0x100962f51 uv_run [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
14: 0x1000d9007 node::NodeMainInstance::Run() [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
15: 0x100072b52 node::Start(int, char**) [/Users/asilvas/.nvm/versions/node/v14.2.0/bin/node]
16: 0x7fff650813d5 start [/usr/lib/system/libdyld.dylib]
Illegal instruction: 4

@lovell
Copy link
Owner

lovell commented May 11, 2020

Thanks, the upstream Node.js PR nodejs/node#33321 should fix the race condition we're seeing.

@asilvas
Copy link
Author

asilvas commented May 19, 2020

I could repro this issue in 14.2 in under a minute reliably. 14.3 has been solid in 10 mins of identical load.

There seems to be doubt that it's resolved all cases, but so far so good for sharp. nodejs/node#33321

@dminkovsky
Copy link

dminkovsky commented May 20, 2020

I was hitting this randomly, and not able to reproduce on a specific input, suggesting it is something like a race condition. Downgrading to node@12 fixed the problem for me. Will upgrade to node 14.3 when its released on brew.

@lovell
Copy link
Owner

lovell commented May 20, 2020

That's great news. From what I can tell the remaining problems being discussed do not affect sharp/libvips as it does not create multiple Buffer instances pointing to the same memory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants