This fails: MOZ_RELEASE_ASSERT(mJSSampling == ACTIVE || mJSSampling == ACTIVE_REQUESTED); STR: * release build of m-c on x86_64-Linux (but this looks target independent) * start up. Set profiler params to: 18MB buffer, 1ms sampling, "," (all threads). * quit * restart, check that abovementioned params have "stuck" * In the thread filter box, change the "," to "GeckoMain,Compositor" * click twice on "restart profiler". It segfaults reliably after the second click. * If that doesn't work, just click as fast as you can on "restart profiler" having changed the text in the box. Getting a stack trace is a bit tricky because it crashes whilst the profiler menu holds the mouse focus (at least for me), leaving the whole display unusable. In the end I ran it in an Xvnc server.

(In reply to Julian Seward [:jseward] from comment #0) > * release build of m-c on x86_64-Linux (but this looks target independent) Yes. The same STR also causes a segfault on MacOS.

I've diagnosed the problem and have fixed it locally. Now I want to write a test case for it.

PseudoStack requires that startJSSampling() and stopJSSampling() calls be interleaved. But currently the conditions guarding those calls don't match: startJSSampling() is guarded by ShouldProfileThread(), and stopJSSampling() is guarded by HasProfile(). It's possible for HasProfile() to be true when ShouldProfileThread() is not true -- e.g. profile many threads, then restart and profile fewer threads, and we end up with live threads that have a profile but aren't being profiled right now -- which leads to assertion failures in stopJSSampling(). This patch makes the stopJSSampling() condition use ShouldProfileThread(), just like the startJSSampling() condition, which fixes the assertion failure.

Try looks good: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c74cf16677a570ccc125eab6d05e5a256dd991b5

https://hg.mozilla.org/integration/mozilla-inbound/rev/e295801c2da9403ec103978ff362506c69752e41 Bug 1355807 - Fix condition guarding stopJSSampling() calls. r=jseward.