Segmentation fault on v8.1.3

Version: v8.1.3
Platform: Linux f0022a84-19f5-4890-ac94-af66da6c237f 3.13.0-112-generic Added DS_Store to gitignore #159-Ubuntu SMP Fri Mar 3 15:26:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Subsystem:

Hi there,
we noticed that we're receiving a Segmentation Fault on node v8.

Here's the backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000d5d9d8 in v8::internal::compiler::StateValuesAccess::size() ()
(gdb) backtrace
#0  0x0000000000d5d9d8 in v8::internal::compiler::StateValuesAccess::size() ()
#1  0x0000000000c699ed in v8::internal::compiler::InstructionSelector::GetFrameStateDescriptor(v8::internal::compiler::Node*) ()
#2  0x0000000000c705d2 in v8::internal::compiler::InstructionSelector::VisitCall(v8::internal::compiler::Node*, v8::internal::compiler::BasicBlock*) ()
#3  0x0000000000c727db in v8::internal::compiler::InstructionSelector::VisitNode(v8::internal::compiler::Node*) ()
#4  0x0000000000c7346b in v8::internal::compiler::InstructionSelector::VisitBlock(v8::internal::compiler::BasicBlock*) ()
#5  0x0000000000c73757 in v8::internal::compiler::InstructionSelector::SelectInstructions() ()
#6  0x0000000000d0abf9 in void v8::internal::compiler::PipelineImpl::Run<v8::internal::compiler::InstructionSelectionPhase, v8::internal::compiler::Linkage*>(v8::internal::compiler::Linkage*) ()
#7  0x0000000000d0e637 in v8::internal::compiler::PipelineImpl::ScheduleAndSelectInstructions(v8::internal::compiler::Linkage*, bool) ()
#8  0x0000000000d1166d in v8::internal::compiler::PipelineImpl::OptimizeGraph(v8::internal::compiler::Linkage*) ()
#9  0x0000000000d119f7 in v8::internal::compiler::PipelineCompilationJob::ExecuteJobImpl() ()
#10 0x0000000000d95360 in v8::internal::CompilationJob::ExecuteJob() ()
#11 0x0000000000d9c4e3 in v8::internal::(anonymous namespace)::GetOptimizedCode(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Compiler::ConcurrencyMode, v8::internal::BailoutId, v8::internal::JavaScriptFrame*) ()
#12 0x0000000000d9cd42 in v8::internal::(anonymous namespace)::GetLazyCode(v8::internal::Handle<v8::internal::JSFunction>) ()
#13 0x0000000000d9d16c in v8::internal::Compiler::Compile(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Compiler::ClearExceptionFlag)
    ()
#14 0x0000000001129605 in v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::internal::Isolate*) ()
#15 0x000026325978437d in ?? ()
#16 0x00002632597842c1 in ?? ()
#17 0x00007fffffff7e20 in ?? ()
#18 0x0000000000000006 in ?? ()
#19 0x00007fffffff7e78 in ?? ()
#20 0x00002632597846b9 in ?? ()
#21 0x0000331b07904609 in ?? ()
#22 0x00003419a6682311 in ?? ()
#23 0x0000331b07904609 in ?? ()
#24 0x0000000100000000 in ?? ()
#25 0x0000263259784441 in ?? ()
#26 0x000000000000001a in ?? ()
#27 0x00007fffffff7ed0 in ?? ()
#28 0x000026325a958389 in ?? ()
#29 0x000008bc77192499 in ?? ()
#30 0x00003419a6682311 in ?? ()
#31 0x00003419a6682201 in ?? ()
#32 0x0000227c15536c51 in ?? ()
#33 0x00003419a6682311 in ?? ()
#34 0x0000331b07904609 in ?? ()
#35 0x000009f4f378ac19 in ?? ()
#36 0x0000227c15536bc9 in ?? ()
#37 0x0000227c15536b71 in ?? ()
#38 0x00007fffffff7f00 in ?? ()
#39 0x000026325978579b in ?? ()
#40 0x00003419a6682311 in ?? ()
#41 0x0000000100000000 in ?? ()
#42 0x0000227c15536bc9 in ?? ()
#43 0x000000000000001e in ?? ()
#44 0x00007fffffff7f60 in ?? ()
#45 0x000026325ab6adf0 in ?? ()
#46 0x000008bc77192499 in ?? ()
#47 0x00003419a6682311 in ?? ()
#48 0x00007fffffff7fe0 in ?? ()
#49 0x0000000000aa6992 in v8::Object::Get(v8::Local<v8::Context>, v8::Local<v8::Value>) ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Here's a list of compiled modules:

~ $ find node_modules/ -name "*.node"
node_modules/fsevents/build/Release/.node
node_modules/fsevents/build/Release/fse.node
node_modules/fsevents/lib/binding/Release/node-v11-darwin-x64/fse.node
node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node
node_modules/fsevents/lib/binding/Release/node-v48-darwin-x64/fse.node
node_modules/fsevents/lib/binding/Release/node-v47-darwin-x64/fse.node
node_modules/fsevents/lib/binding/Release/node-v46-darwin-x64/fse.node
node_modules/node-sass/vendor/linux-x64-57/binding.node
node_modules/kerberos/build/Release/obj.target/kerberos.node
node_modules/kerberos/build/Release/kerberos.node

We tried to downgrade to latest v7 and the issue is not there, so it must be something with node-v8.

Thanks!
Stefano

@stefanosala

@stefanosala Can you post the output of disassemble and info registers? Does running with --noturbo make a difference? Can you exclude kerberos and node-sass? (fsevents won't be loaded on your system, it's MacOS-only.)

@bnoordhuis

Thanks @bnoordhuis for looking into the issue!

--noturbo doesn't make any difference.

Here's the disassemble output: https://gist.github.com/stefanosala/f76b0d3d577714fb3542a20f8930224b

Here's the info registers output:

(gdb) info registers
rax            0x80000000f	34359738383
rbx            0x16	22
rcx            0x9	9
rdx            0x313d038	51630136
rsi            0x7fffffff6e90	140737488318096
rdi            0x7fffffff6f00	140737488318208
rbp            0x7fffffff6ff0	0x7fffffff6ff0
rsp            0x7fffffff6e80	0x7fffffff6e80
r8             0x4	4
r9             0x373c6f0	57919216
r10            0x0	0
r11            0x349bf40	55164736
r12            0x31430b0	51654832
r13            0x7fffffff7310	140737488319248
r14            0x313d2d0	51630800
r15            0x170095e	24119646
rip            0xd5d9d8	0xd5d9d8 <v8::internal::compiler::StateValuesAccess::size()+136>
eflags         0x10246	[ PF ZF IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0

Removing all compiled modules doesn't make any difference either.

Thanks!
Cheers

Could you isolate the function that triggers this bug?
You can use call _v8_internal_Print_StackTrace() to get the JS stack trace.

Thanks. Looks like SparseInputMask::InputIterator::GetReal() returns a bad node pointer: 0x80000000f.

Can you try a debug build and see what happens? ./configure --debug && make -j8 - the binary is called node_g.

Is there an easy way for us to reproduce?

Looks like SparseInputMask::InputIterator::GetReal() returns a bad node pointer: 0x80000000f.

But just to be sure: what does p *('v8::internal::compiler::Node'*)$rax print?

@targos

@targos here's the JS stack trace: https://gist.github.com/stefanosala/1345fa59d02a77f89531eca059f0d03c

@bnoordhuis

@bnoordhuis I'll try compiling a debug version.

@bnoordhuis

@bnoordhuis it prints:

(gdb) p *('v8::internal::compiler::Node'*)$rax
No symbol "v8::internal::compiler::Node" in current context

@stefanosala

@stefanosala What about simply p *(long*)$rax?

I'd delete that gist again if I were you, it contains sensitive information.

@bnoordhuis

@bnoordhuis thanks, deleted.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000d5d9d8 in v8::internal::compiler::StateValuesAccess::size() ()
(gdb) p *(long*)$rax
Cannot access memory at address 0x6e6f697461727473

@bnoordhuis

Hi @bnoordhuis,
this is the output from node_g:

#
# Fatal error in ../deps/v8/src/compiler/node-properties.cc, line 69
# Check failed: 1 == OperatorProperties::GetFrameStateInputCount(node->op()) (1 vs. 0).
#

==== C stack trace ===============================

    node-v8.1.3/node_g(v8::base::debug::StackTrace::StackTrace()+0x1d) [0x2916d3d]
    node-v8.1.3/node_g(V8_Fatal+0xf9) [0x2912b68]
    node-v8.1.3/node_g(v8::internal::compiler::NodeProperties::GetFrameStateInput(v8::internal::compiler::Node*)+0x64) [0x1ca1db2]
    node-v8.1.3/node_g(v8::internal::compiler::JSBinopReduction::CreateFrameStateForLeftInput()+0x1c) [0x1c2748a]
    node-v8.1.3/node_g(v8::internal::compiler::JSBinopReduction::ConvertInputsToNumber()+0xde) [0x1c2624a]
    node-v8.1.3/node_g(v8::internal::compiler::JSTypedLowering::ReduceSpeculativeNumberBinop(v8::internal::compiler::Node*)+0x7c) [0x1c2869c]
    node-v8.1.3/node_g(v8::internal::compiler::JSTypedLowering::Reduce(v8::internal::compiler::Node*)+0x5d9) [0x1c33595]
    node-v8.1.3/node_g(v8::internal::compiler::GraphReducer::Reduce(v8::internal::compiler::Node*)+0x9e) [0x1b845b8]
    node-v8.1.3/node_g(v8::internal::compiler::GraphReducer::ReduceTop()+0x22f) [0x1b84967]
    node-v8.1.3/node_g(v8::internal::compiler::GraphReducer::ReduceNode(v8::internal::compiler::Node*)+0xe1) [0x1b8431b]
    node-v8.1.3/node_g(v8::internal::compiler::GraphReducer::ReduceGraph()+0x32) [0x1b84518]
    node-v8.1.3/node_g(v8::internal::compiler::TypedLoweringPhase::Run(v8::internal::compiler::PipelineData*, v8::internal::Zone*)+0x4df) [0x1cb672f]
    node-v8.1.3/node_g(void v8::internal::compiler::PipelineImpl::Run<v8::internal::compiler::TypedLoweringPhase>()+0x4f) [0x1cbc08d]
    node-v8.1.3/node_g(v8::internal::compiler::PipelineImpl::CreateGraph()+0x4b8) [0x1cb9060]
    node-v8.1.3/node_g(v8::internal::compiler::PipelineCompilationJob::PrepareJobImpl()+0x2d9) [0x1cb4c7f]
    node-v8.1.3/node_g(v8::internal::CompilationJob::PrepareJob()+0x264) [0x1db5630]
    node-v8.1.3/node_g() [0x1db8633]
    node-v8.1.3/node_g() [0x1db9497]
    node-v8.1.3/node_g() [0x1dba42a]
    node-v8.1.3/node_g(v8::internal::Compiler::Compile(v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Compiler::ClearExceptionFlag)+0x158) [0x1dbb364]
    node-v8.1.3/node_g() [0x23168cf]
    node-v8.1.3/node_g(v8::internal::Runtime_CompileLazy(int, v8::internal::Object**, v8::internal::Isolate*)+0x112) [0x2316723]
    [0xdf91a784204]
Illegal instruction

Do you need anything else?

@stefanosala

@stefanosala Thanks. Can you check in gdb what p *node prints in frame 3 (the GetFrameStateInput frame) and likewise its members (p *node->op_, p *node->type_, etc.)?

If you have the time and inclination, it would be helpful to know if you also experience the issue with the master branch which bundles a newer V8 version. If it's fixed there, we can look into isolating and back-porting the fix.

@bnoordhuis

@bnoordhuis the issue is not present building from master.

Can you check in gdb what p *node prints in frame 3 (the GetFrameStateInput frame) and likewise its members (p *node->op_, p *node->type_, etc.)?

I'm not sure how to do that, I'm sorry :(

Is there some kind of asm.js code involved? I'm a bit puzzled about the stack trace.

@bmeurer

Nope @bmeurer, no asm.js involved in the project :(

@mathiasbynens

Can you check with the latest Node Canary?

cc @mathiasbynens @schuay @nodejs/v8

@bmeurer

@bmeurer not happening on canary

Can you also try with Node 8.2.0RC1 please?

No issue on 8.2.0RC1 .... /shrug :)

@targos

Ok, thanks. @targos do we also have downloadable Node w/ V8 6.0?

I don't think so. But if 5.9 doesn't have the issue, do we need to check 6.0?

Oh, right, sorry. I was confused.

I guess everything will be magically fixed on 8.2 then? 👯 :)

I don't follow the above - it's totally out of my league! - but if it helps, I've observed the following:

docker run -it node:8.1.3-alpine /bin/sh -c 'npm i bcrypt && node -e '"'"'require("bcrypt").genSalt(10)'"'" produces output:

<SNIP>
npm WARN enoent ENOENT: no such file or directory, open '/package.json'
npm WARN !invalid#1 No description
npm WARN !invalid#1 No repository field.
npm WARN !invalid#1 No README data
npm WARN !invalid#1 No license field.

+ bcrypt@1.0.2
added 115 packages in 7.118s
npm info ok
Segmentation fault

Hey folks, wait a min... I tried with 8.2.1 and the issue is still there :(

8.2.1 is still using V8 5.8. See #13515 and #14004 for in-progress updates to 5.9 and 6.0 respectively.

#14004 landed and will be released in v8.3.0. I'll close this out, cheers.

Navigation Menu

Repository navigation

Segmentation fault on v8.1.3 #14069

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segmentation fault on v8.1.3 #14069

Description

Activity

bnoordhuis commented on Jul 4, 2017

stefanosala commented on Jul 4, 2017

targos commented on Jul 4, 2017

bnoordhuis commented on Jul 4, 2017

bnoordhuis commented on Jul 4, 2017

stefanosala commented on Jul 4, 2017

stefanosala commented on Jul 4, 2017

stefanosala commented on Jul 4, 2017

bnoordhuis commented on Jul 4, 2017

stefanosala commented on Jul 4, 2017

stefanosala commented on Jul 5, 2017

bnoordhuis commented on Jul 5, 2017

stefanosala commented on Jul 5, 2017

3 remaining items

bmeurer commented on Jul 5, 2017

stefanosala commented on Jul 5, 2017

bmeurer commented on Jul 6, 2017

stefanosala commented on Jul 6, 2017

bmeurer commented on Jul 6, 2017

stefanosala commented on Jul 6, 2017

bmeurer commented on Jul 7, 2017

targos commented on Jul 7, 2017

bmeurer commented on Jul 7, 2017

stefanosala commented on Jul 7, 2017

georgecrawford commented on Jul 7, 2017

stefanosala commented on Jul 21, 2017

bnoordhuis commented on Jul 21, 2017

bnoordhuis commented on Aug 3, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions