New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 780412 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Recording trace leads to renderer crash

Project Member Reported by yhirano@chromium.org, Nov 1 2017

Issue description

Chrome Version: ToT (513016)
OS: Linux

What steps will reproduce the problem?
(1) Record trace with chrome://tracing
(2) Load a page
(3) Crash

Received signal 11 SEGV_MAPERR 000000000210
#0 0x7f8967ff0bb7 base::debug::StackTrace::StackTrace()
#1 0x7f8967ff071f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f89680fa330 <unknown>
#3 0x7f89610a12e1 blink::KURL::KURL()
#4 0x7f8961f0d38f blink::ClassicPendingScript::UrlForClassicScript()
#5 0x7f896225297a blink::(anonymous namespace)::GetTraceArgsForScriptElement()
#6 0x7f8962251a2e blink::(anonymous namespace)::TraceParserBlockingScript()
#7 0x7f8962251492 blink::HTMLParserScriptRunner::ProcessScriptElement()
#8 0x7f8962245173 blink::HTMLDocumentParser::ProcessTokenizedChunkFromBackgroundParser()
#9 0x7f8962243bdb blink::HTMLDocumentParser::PumpPendingSpeculations()
#10 0x7f8960f25daf blink::TaskHandle::Runner::Run()
#11 0x7f8967ff1667 base::debug::TaskAnnotator::RunTask()
#12 0x7f896115993d blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#13 0x7f89611579a9 blink::scheduler::TaskQueueManager::DoWork()
#14 0x7f8967ff1667 base::debug::TaskAnnotator::RunTask()
#15 0x7f8968017b24 base::MessageLoop::RunTask()
#16 0x7f89680180c7 base::MessageLoop::DoWork()
#17 0x7f8968018cfa base::MessagePumpDefault::Run()
#18 0x7f896803e9bf base::RunLoop::Run()
#19 0x7f89663f6c26 content::RendererMain()
#20 0x7f8966511094 content::RunZygote()
#21 0x7f8966512292 content::ContentMainRunnerImpl::Run()
#22 0x7f89684d045c service_manager::Main()
#23 0x7f8966510dd2 content::ContentMain()
#24 0x55d791cea1c4 ChromeMain
#25 0x7f895cea0f45 __libc_start_main
#26 0x55d791cea029 <unknown>
  r8: 00007ffe36d4ccb0  r9: 00007ffe36d4cca8 r10: 000000002f18622b r11: 0000000000000293
 r12: 000007afabb602c0 r13: 00001b7c78fec190 r14: 0000000000000210 r15: 00007ffe36d4ceb0
  di: 00007ffe36d4cde0  si: 0000000000000210  bp: 0000000000000001  bx: 00007ffe36d4cde0
  dx: 0000000000000000  ax: 0000000000000210  cx: d00e8f959d5f8800  sp: 00007ffe36d4cd80
  ip: 00007f89610a12e1 efl: 0000000000010202 cgf: 0000000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000210
[end of stack trace]
Calling _exit(1). Core file will not be generated.

 

Comment 1 by maxlg@chromium.org, Nov 2 2017

Blocking: 775098
Cc: rmis...@chromium.org maxlg@chromium.org nednguyen@chromium.org
The same bug happens to me on ToT. I've also tested it on "Version 62.0.3202.75 (Official Build) (64-bit)" but doesn't happen there. 

It happens when we are recording the "blink" category.

It should impact other benchmarks using this category as well, like these:

https://cs.chromium.org/chromium/src/tools/perf/measurements/image_decoding.py?q=AddIncludedCategory+%27blink%27&dr=C&l=45
https://cs.chromium.org/chromium/src/tools/perf/measurements/task_execution_time.py?q=AddIncludedCategory+%27blink%27&dr=C&l=26

Comment 2 by maxlg@chromium.org, Nov 3 2017

It's interesting that the bug is not triggered by running a benchmark locally. It's triggered when we manually open a browser and use tracing and open a new page.
Components: Blink>HTML>Script
Labels: -Type-Bug -Pri-3 Pri-1 Type-Bug-Regression
Owner: hirosh...@chromium.org
Status: Started (was: Untriaged)
Started.

Suspected CL is:
https://chromium-review.googlesource.com/c/chromium/src/+/734137

But many CLs landed after that depend on the CL, so I cannot simply revert the CL only.
I'll investigate and try to fix the crash today.

Also bots are crashing ( Issue 780598 ).
Project Member

Comment 6 by bugdroid1@chromium.org, Nov 4 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9a942faab2c8850c567c50fe73dc0d4a4976e4d8

commit 9a942faab2c8850c567c50fe73dc0d4a4976e4d8
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Sat Nov 04 14:03:05 2017

Fix crashes in ClassicPendingScript::UrlForClassicScript()

Follow-up / bug fix of [1].

Before [1], the URL for tracing is obtained only when
ScriptLoader::GetResource() is non-null (i.e. for classic
external scripts). But after [1]
ClassicPendingScript::UrlForClassicScript() tries to get the URL
even for classic inline scripts, and thus is crashing.

This CL adds checks to avoid null-dereferencing GetResource()
(i.e. returns NullURL() for classic inline scripts).

[1] https://chromium-review.googlesource.com/734137

Bug:  780598 ,  780412 , 686281,  777612 
Change-Id: I775faa270ecb7788a448e703db0689a17ea80aee
Reviewed-on: https://chromium-review.googlesource.com/754101
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Commit-Queue: Kouhei Ueno <kouhei@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514049}
[modify] https://crrev.com/9a942faab2c8850c567c50fe73dc0d4a4976e4d8/third_party/WebKit/Source/core/dom/ClassicPendingScript.cpp

Labels: Needs-Feedback
Tested this issue on Linux Ubuntu 14.04 using chrome latest #64.0.3260.0 as per the below steps:
1. Launched chrome
2. Navigate to chrome://tracing
3. Click on 'load' button
4. Select any json file
5. Observed all the results without any crash.
6. Reload the page
7. Click on 'Record' button
8. Select any one of the option
9. stop after few seconds
10. Trace for the above session imported successfully without any issue.

Please find the attached screencast for reference & please confirm on the fix & expected behavior on the same.

Thanks in advance..!
780412.mp4
2.4 MB View Download
Status: Fixed (was: Started)

Comment 9 by dproy@chromium.org, Feb 20 2018

Blocking: -775098

Sign in to add a comment