New issue
Advanced search Search tips

Issue 803005 link

Starred by 1 user
Status: Duplicate
Merged: issue 728979
Owner: ----
Closed: Jan 2018
Cc:
jgruber@chromium.org
clemensh@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Stack-overflow in __GI___pthread_mutex_lock

Project Member Reported by ClusterFuzz, Jan 17 2018 
Detailed report: https://clusterfuzz.com/testcase?key=5873026393702400

Fuzzer: v8_builtins_generator
Job Type: linux_asan_d8_v8_arm_dbg
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0xff7fffec
Crash State:
  __GI___pthread_mutex_lock
  v8::internal::Simulator::WriteW
  v8::internal::Simulator::HandleVList
  
Sanitizer: address (ASAN)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5873026393702400

No crash found using linux_d8_dbg job.

Issue manually filed by: machenbach

See https://github.com/google/clusterfuzz-tools for more information.

Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.

Comment 1 by machenb...@chromium.org, Jan 17 2018

Cc: jgruber@chromium.org
Labels: -Pri-1 Pri-2
Bug surfacing from arm simulator from builtins fuzzer. I downloaded build and test case and was able to repro twice in 4 attempts. Sadly after those two it doesn't repro anymore. Maybe depends on warmed up cache?

Comment 2 by machenb...@chromium.org, Jan 17 2018 

Here's a trick. I added the test case as mjsunit test case adding the line:
// Flags: --expose-gc --expose_natives_as natives --expose-gc --allow-natives-syntax --debug-code --es-staging --enable-slow-asserts --verify-heap --invoke-weak-callbacks --omit-quit --disable-in-process-stack-traces

I downloaded the build into out.gn/d8-arm-asan-linux-debug-v8-component-50634

Now it repros with:
tools/run-tests.py --outdir=out.gn/d8-arm-asan-linux-debug-v8-component-50634 mjsunit/clusterfuzz-testcase-5873026393702400 --variants=default --random-seed-stress-count=200 --random-seed=831991246

Repros in 6 of 200.

Comment 3 by machenb...@chromium.org, Jan 17 2018

Cc: clemensh@chromium.org
Stack: http://shortn/_lfmctGFEaO

+clusterfuzz sheriff

Comment 4 by jgruber@chromium.org, Jan 17 2018 

Looks like a normal stack overflow in Error.p.toString. I guess depending on the stack layout it might either throw a RangeError or overflow in C++. 

Doesn't seem actionable from a quick glance.

Comment 5 by clemensh@chromium.org, Jan 17 2018

Mergedinto: 728979
Status: Duplicate (was: Untriaged)
I agree with Jakobs analysis. We had this several times already: The stack frames with asan get too big to fit in the red zone at the end of the stack. The StackCheck in JS or wasm code checks against a stack limit which leaves some space for a few additional (C++) stack frames, but under certain conditions this space is not sufficient. We track this in crbug.com/728979, hence I merge this into that bug.
►

Sign in to add a comment