Bugzilla

A few notes as I dig into this:

1. the current set of files output by the profiler is ambiguous - it's basically meant to use a pool of randomly named files to avoid filename conflicts between multiple runs. 
2. it does not include the pid, so no way to see if a child process wrote anything
3. good news, we can use an env var to control this filename
4. bad news, doing so shows the child process writes nada/nothing/niente.
5. turning off sandboxing seems like a red herring - I think there was something wrong with my windows setup (or perhaps with windows sandboxing around the time I wrote the patch or whatever). It makes no difference here atm (though it is of course possible that after fixing whatever the issue is we have right now, we'd still run into sandboxing)
6. profiles are dumped at exit and kept in memory
7. searching the web finds me http://mysql-qa.blogspot.com/2009/06/kill-exit-exit-and-issues-getting-gcov.html . Our child process uses `_exit`, as far as I can tell, presumably because there shouldn't be anything to do when it exits?
8. Annnnd looking for code in our codebase brings me to https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/dom/ipc/ContentChild.cpp#2334-2339 which brings me to bug 1460929.

Nathan, does that look right? Do we just want to expand that define so we don't _exit() in the profiling build, just like in coverage builds?

A few notes as I dig into this:

1. the current set of files output by the profiler is ambiguous - it's basically meant to use a pool of randomly named files to avoid filename conflicts between multiple runs. 
2. it does not include the pid, so no way to see if a child process wrote anything
3. good news, we can use an env var to control this filename and make it include the pid
4. bad news, doing so shows the child process writes nada/nothing/niente.
5. turning off sandboxing seems like a red herring - I think there was something wrong with my windows setup (or perhaps with windows sandboxing around the time I wrote the patch or whatever). It makes no difference here atm (though it is of course possible that after fixing whatever the issue is we have right now, we'd still run into sandboxing)
6. profiles are dumped at exit and kept in memory
7. searching the web finds me http://mysql-qa.blogspot.com/2009/06/kill-exit-exit-and-issues-getting-gcov.html . Our child process uses `_exit`, as far as I can tell, presumably because there shouldn't be anything to do when it exits?
8. Annnnd looking for code in our codebase brings me to https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/dom/ipc/ContentChild.cpp#2334-2339 which brings me to bug 1460929.

Nathan, does that look right? Do we just want to expand that define so we don't _exit() in the profiling build, just like in coverage builds?