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

Issue 731804 link

Starred by 2 users
Status: Assigned
Owner:
█ petermarshall@chromium.org
OOO until 2019-02-10
Cc:
leszeks@chromium.org
benjhayden@chromium.org
█ vdje...@fb.com
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

v8.cpu_profiler causes traceviewer to throws Cannot read property 'sampleTitle' of undefined

Project Member Reported by bgir...@fb.com, Jun 9 2017 
I've been using v8.cpu_profiler a lot but I find that about 1/4 of the time I get this error and lose the trace:
TypeError: Cannot read property 'sampleTitle' of undefined
    at TraceEventImporter.processSample (chrome://tracing/tracing.js:4536:347)
    at TraceEventImporter.processV8Events (chrome://tracing/tracing.js:4555:246)
    at TraceEventImporter.importEvents (chrome://tracing/tracing.js:4561:6)
    at importer (chrome://tracing/tracing.js:1186:232)
    at task.subTask (chrome://tracing/tracing.js:1182:262)
    at Task.run (chrome://tracing/tracing.js:2172:104)
    at runAnother (chrome://tracing/tracing.js:2178:566)
    at runTask (chrome://tracing/tracing.js:2151:57)
    at processIdleWork (chrome://tracing/tracing.js:2156:116)
    at window.requestIdleCallback.timeout (chrome://tracing/tracing.js:2149:81)

What's I see when I look at the trace is that:
- There's a cpuProfile event that references sample id 3 which has not yet been defined.
- There's another cpuProfile event later in the buffer for the same PID but a different TID that defines sample id 3

I actually hit the same error as trace-viewer in my data pipeline to analyze these traces that made the assumption that a sample would always reference a valid sample id definition.

I'm trying to determine if the fault lies in the tracer implementation for not omitting the node type properly or in the viewer for not treating the sample id definition as optional OR fetching it from another TID later in the buffer. It's really a design decission if this data is strictly mandatory or optional.

Comment 1 by vdje...@fb.com, Jun 9 2017

Cc: vdje...@fb.com

Comment 2 by sdy@chromium.org, Jun 13 2017

Labels: -OS-Mac

Comment 3 by sdy@chromium.org, Jun 13 2017 

Sorry for the missing comment :). I'm removing OS=Mac to take this out of the Mac team's queue. If I missed something and it *is* Mac-specific, feel free to re-add.

Comment 4 by ajha@chromium.org, Jul 10 2017

Labels: TE-NeedsTriageHelp
Adding TE-NeedsTriageHelp label to move this out of TE unconfirmed triage queue.
Project Member

Comment 5 by sheriffbot@chromium.org, Jul 10

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by jeremya@chromium.org, Dec 12

Labels: OS-All
Status: Untriaged (was: Archived)
I'm seeing this manifest in current Canary when doing the following:

1. Open data:text/html,<button onclick="console.log('foo')">foo</button>
2. Open a new tab with about:tracing
3. Click "Record", choose manual categories, and deselect everything but the "v8.cpu_profiler" category
4. Start the recording
5. Switch to the data:text/html tab and click the button a few times
6. Switch back to about:tracing and end the recording


Instead of "Cannot read property 'sampleTitle' of undefined", I see:

Error: Conflict id in the profile tree.
    at ProfileTree.add (chrome://tracing/tracing.js:4826:434)
    at TraceEventImporter.processSample (chrome://tracing/tracing.js:5175:13)
    at TraceEventImporter.processV8Events (chrome://tracing/tracing.js:5195:250)
    at TraceEventImporter.importEvents (chrome://tracing/tracing.js:5199:32)
    at importer (chrome://tracing/tracing.js:1312:232)
    at task.subTask (chrome://tracing/tracing.js:1308:268)
    at Task.run (chrome://tracing/tracing.js:2355:95)
    at runAnother (chrome://tracing/tracing.js:2358:371)
    at runTask (chrome://tracing/tracing.js:2334:57)
    at processIdleWork (chrome://tracing/tracing.js:2339:116)

The same steps in Chrome 61 (http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/488533/) produce the error in the title of the commit.

It doesn't seem to repro 100% of the time, but it is rare that it _doesn't_ repro.

Comment 7 by jeremya@chromium.org, Dec 12

Cc: benjhayden@chromium.org leszeks@chromium.org
Ah, actually, I just found  crbug.com/770530  which claims to have fixed the issue in the title, so perhaps this is a different issue! Ccing benjhayden and leszeks who worked on that fix. Happy to open a new bug instead if that's more appropriate.

Comment 8 by b56gir...@gmail.com, Dec 12 

To work around this issue at Facebook we actually filter out malformed v8.cpu_profiler events. IIRC the trace format references IDs that don't get associated names.

Comment 9 by leszeks@chromium.org, Dec 12

Owner: petermarshall@chromium.org
+petermarshall

Comment 10 by benhenry@google.com, Jan 11

Status: Assigned (was: Untriaged)
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.
►

Sign in to add a comment