Open Bug 1746599 Opened 4 years ago Updated 4 years ago

Investigate when&how profiler_stop gets called multiple times

Categories

(Core :: Gecko Profiler, defect, P3)

Product:
Core
Component:
Gecko Profiler
Type:
defect

Tracking

()

People

(Reporter: mozbugz, Unassigned)

References

Details

While working on bug 1734867, I hit an issue when I initially assumed that calls to Ensure/ReleaseBufferForMainThreadAddMarker from locked_profiler_start/stop should be exactly matched.
But asserting that led to crashes in some tests, see bug 1734867 comment 12 for details.

To reproduce it, in ReleaseBufferForMainThreadAddMarker change if (sBufferForMainThreadAddMarkerRefCount == 0) {...} to MOZ_ASSERT(sBufferForMainThreadAddMarkerRefCount > 0); and run tests like test-linux1804-64-qr/debug-mochitest-browser-chrome-swr-fis-e10s-2... (IIRC, running just one test locally didn't reproduce the issue!)

From a quick read of the profiler start/stop code, it looked like this shouldn't happen: start asserts that ActivePS doesn't exist, and creates it; stop asserts that ActivePS exists, and destroys it. So a 2nd unexpected stop should assert there, before even trying to call ReleaseBufferForMainThreadAddMarker. To be investigated further...

You need to log in before you can comment on or make changes to this bug.