Repository navigation
Crash during Garbage collection in TLSWrap #17097
Copy link
Copy link
Closed
Labels
c++Issues and PRs that require attention from people who are familiar with C++.Issues and PRs that require attention from people who are familiar with C++.tlsIssues and PRs related to the tls subsystem.Issues and PRs related to the tls subsystem.
Description
- Version:v6.11.0
- Platform:Amazon Linux 4.9.27-14.31.amzn1.x86_64
- OpenSSL version: OpenSSL 1.0.1k-fips
I am experiencing a crash in PostGarbageCollectionProcessing call.
I do not have any reproducible case. But it happens 1-2 times a day in production.
Whenever I have got this crash, we were connecting to AWS's endpoint.
Below is my stack trace:
(lldb) v8 bt
* SBThread: tid = 0x0000 * frame #0: 0x000000000111b346 node`node::TLSWrap::~TLSWrap() + 358
frame #1: 0x000000000111b421 node`node::TLSWrap::~TLSWrap() + 17
frame #2: 0x0000000000c85e5c node`v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool) + 252
frame #3: 0x0000000000c860ba node`v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector, v8::GCCallbackFlags) + 42
frame #4: 0x0000000000ca6e37 node`v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) + 535
frame #5: 0x0000000000ca771a node`v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags) + 330
frame #6: 0x0000000000ca932e node`v8::internal::Heap::HandleGCRequest() + 222
frame #7: 0x0000000000c55bac node`v8::internal::StackGuard::HandleInterrupts() + 796
frame #8: 0x0000000000eb75fc node`v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) + 380
frame #9: 0x00001ee4063079a7 <exit>
Contents of registers:
(lldb) register read
General Purpose Registers:
rax = 0x0000000008617ac8
rbx = 0x0000000008617950
rcx = 0x1baffed00baffedf
rdx = 0x0000000000000000
rdi = 0x0000000000000000
rsi = 0x0000000008617ac8
rbp = 0x00007fff78159b10
rsp = 0x00007fff78159b00
r8 = 0x0000000000000001
r9 = 0x00000000084fda90
r10 = 0x0007312ef242a226
r11 = 0x0000000000000246
r12 = 0x0000000000000000
r13 = 0x00000000000000ce
r14 = 0x0000000000000001
r15 = 0x0000000004dc9e80
rip = 0x000000000111b346 node`node::TLSWrap::~TLSWrap() + 358
rflags = 0x0000000000010246
cs = 0x0000000000000033
fs = 0x0000000000000000
gs = 0x0000000000000000
ss = 0x000000000000002b
ds = 0x0000000000000000
es = 0x0000000000000000
Disassembly of the top frame is attached here: disassembly.log
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
c++Issues and PRs that require attention from people who are familiar with C++.Issues and PRs that require attention from people who are familiar with C++.tlsIssues and PRs related to the tls subsystem.Issues and PRs related to the tls subsystem.
Activity
bnoordhuis commentedon Nov 17, 2017
Looks like the instruction pointer ended up in an all zeros page. Two questions:
node -p process.versionsandnode -p process.configprint?surajwy commentedon Nov 17, 2017
Also, FYI, we have also tried this on node v8.6 and this crash was still happening.
bnoordhuis commentedon Nov 17, 2017
Does your application contain sensitive information? If it doesn't, perhaps you can upload a core dump from the latest v6.x or v8.x? If you don't want to share the link publicly, my email is info@bnoordhuis.nl.
surajwy commentedon Nov 17, 2017
Yes, my app contains sensitive information. Won't be able to share. Sorry about that.
We are trying to move our app from node v0.10.32 to an LTS node version. There are 2 more types of crashes and I will open separate git issues for them. We do have some add-on modules, but with these crash dumps, I am not able to pinpoint any issues with them.
addaleax commentedon Dec 10, 2017
@surajwy Is there a chance you could try the patch from #17478?
surajwy commentedon Dec 15, 2017
@addaleax, Yes, I will give it a try next week.
apapirovski commentedon Dec 18, 2017
This got fixed in #17478 but the RegExp didn't pick it up due to the struck out words. @surajwy feel free to reopen if the issue persists after building from master with that patch. Thanks!