JSON Profile Parse Error

[gregtatum]

I've seen this one in the wild, and caught it. This one was on a wasm recording.

error-profile.json.zip

[gregtatum]

It's line 232810.

...
    "data": [
     
,
     [
      82,
      10553395.239479,
      {"type": "GCSlice", "startTime": 10553395.239479, "endTime": 10553398.511756001, "timings": {
...

[julienw]

Current educated guess: this comes from https://searchfox.org/mozilla-central/rev/b0098afaeaad24a6752aa418ca3e86eade5fab17/tools/profiler/core/ThreadInfo.cpp#230-233

      if (aSavedStreamedMarkers) {
        MOZ_ASSERT(aSinceTime == 0);
        aWriter.Splice(aSavedStreamedMarkers);
      }
      // then calls StreamMarkersToJSON

aSavedStreamedMarkers itself comes from https://searchfox.org/mozilla-central/rev/b0098afaeaad24a6752aa418ca3e86eade5fab17/tools/profiler/core/ThreadInfo.cpp#271-280
in ThreadInfo::FlushSamplesAndMarkers:

    SpliceableChunkedJSONWriter b;
    b.StartBareList();
    {
      aBuffer.StreamMarkersToJSON(b, mThreadId, aProcessStartTime,
                                  /* aSinceTime = */ 0, *mUniqueStacks);
    }
    b.EndBareList();
    mSavedStreamedMarkers = b.WriteFunc()->CopyData();

My guess is that we have no markers and we end up with an empty mSavedStreamedMarkers. So aSavedStreamedMarkers later is not null, but empty. So we end up writing it (see splice implementation, sets "mNeedsComma" to true) even if it's empty, and then adding a comma, which looks a lot like we see in the json above.

So 2 possible ways to fix this:

1. in FlushSamplesAndMarkers, set mSavedStreamedMarkers to nullptr if the list is empty.
2. in StreamSamplesAndMarkers, check that aSavedStreamedMarkers isn't empty. But I think we should trim it first so that we're sure it's not just empty spaces.

So I'd rather go with 1 (and likely fix the similar code for samples above).

[julienw]

Although I don't know how to check if the list is empty for this thread id :) Maybe 2 is easier then.

[julienw]

I reproduce 100% with the following STR:

1. Configure the profile to capture workers (add ,Worker in the list of threads to profile)
2. Start the profiler.
3. Open the debugger
4. Close the devtools
5. Capture

I think this confirms my guess:

• if we don't capture workers, we don't have the issue
• if we don't close the devtools, we don't have the issue

=> so my guess is that one of the debugger's worker doesn't add any marker.

I tried to reproduce with a simpler example https://everlong.org/mozilla/testcase-worker/ but this doesn't reproduce much (I think I reproduced 1 out of 10).

[julienw]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1428076 because this will need a gecko patch. Closing here.

[julienw]

reopning for tracking

[julienw]

Autolanding in progress in https://bugzilla.mozilla.org/show_bug.cgi?id=1428076

[julienw]

done !