The profiler is initialized at XRE_main(), and remember tids of threads. It sends signals to the threads of tids for sampling, but the threads were recreated with different tids in content processes, so the signals are not sent correctly.

Patrick, we need to fix this ASAP please. It's a 1.3 blocker...

Fix the bug that b2g fails to start using ./profile.sh start: - Freeze the sampler thread in the Nuwa process and then recreate it in the spawned child. - Set native thread name for the forzen/recreated thread. Native thread name ("SamplerThread") is used in determining whether the profiler is started. We track native thread names in the Nuwa process and set them in the spawned child. With this patch, when we ./profile.sh capture, it doesn't return the profiling data for the Nuwa process, but we generally don't care the Nuwa process, whose threads are mostly frozen.

Push to try: https://tbpl.mozilla.org/?tree=Try&rev=bf9ff81c04d8

(In reply to Cervantes Yu from comment #2) - Also wrap tgkill() call, which is used in the profiler to send SIGPROF to registered threads.

Comment on attachment 8363572 [details] [diff] [review] Fix profiler breakage when the Nuwa process is enabled Review of attachment 8363572 [details] [diff] [review]: ----------------------------------------------------------------- Only looked at platform-linux.cc ::: tools/profiler/platform-linux.cc @@ +271,5 @@ > static void* initialize_atfork = setup_atfork(); > # endif > > +#ifdef MOZ_NUWA_PROCESS > + if(IsNuwaProcess()) { Can we get some documentation for this? I don't expect people contributing to the profiler to have knowledge of Gecko going forward.

Comment on attachment 8363572 [details] [diff] [review] Fix profiler breakage when the Nuwa process is enabled Review of attachment 8363572 [details] [diff] [review]: ----------------------------------------------------------------- ::: mozglue/build/Nuwa.cpp @@ +304,5 @@ > + tinfo; > + tinfo = tinfo->getNext()) { > + if (tinfo->origNativeThreadID == threadID) { > + return thrinfo = tinfo; > + } You're returning with the lock held here ...

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) (AFK Jan 22/23) from comment #6) > Comment on attachment 8363572 [details] [diff] [review] > Fix profiler breakage when the Nuwa process is enabled > > Review of attachment 8363572 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: mozglue/build/Nuwa.cpp > @@ +304,5 @@ > > + tinfo; > > + tinfo = tinfo->getNext()) { > > + if (tinfo->origNativeThreadID == threadID) { > > + return thrinfo = tinfo; > > + } > > You're returning with the lock held here ... Ah, an extra return sneaked in this assignment. Thanks for catching this.

- Add comment to the freezing of the sampler thread. - Fix returning from the added GetThreadInfo() with the lock held.

Comment on attachment 8364191 [details] [diff] [review] Fix profiler breakage when the Nuwa process is enabled Review of attachment 8364191 [details] [diff] [review]: ----------------------------------------------------------------- ::: mozglue/build/Nuwa.cpp @@ +303,5 @@ > + for (thread_info_t *tinfo = sAllThreads.getFirst(); > + tinfo; > + tinfo = tinfo->getNext()) { > + if (tinfo->origNativeThreadID == threadID) { > + thrinfo = tinfo; and break, presumably.

Tests without Nuwa: https://tbpl.mozilla.org/?tree=Try&rev=81f67142b87b

Tests with Nuwa enabled: https://tbpl.mozilla.org/?tree=Try&rev=ea90368e8a8b

Try (only emulator, which were not running in previous try push) Without Nuwa: https://tbpl.mozilla.org/?tree=Try&rev=2b9a3a1966f1 With Nuwa: https://tbpl.mozilla.org/?tree=Try&rev=823ff7d11019