Default process logs created by InitLog should contain the pid

Assigned to



3 years ago
3 years ago


(Reporter: mccr8, Assigned: mccr8)



Firefox Tracking Flags

(Not tracked)



(4 attachments)



3 years ago
InitLog includes the pid for non-default processes, creating logs with names like:
For a default process, it does not do that, giving log names like:
This only works if we have a single default process.  As bug 1067958 has shown, this is not guaranteed (although multiple default processes almost certainly indicates a bug somewhere).  I think the format of the default process logs should be changed to the form:

This will match the format of the rest and separate out different default processes.  It will also allow removing the weird code in processLeakLog and processSingleLeakLog for handling the case where the regexp fails, and let us hard fail when the regexp doesn't match, covering another place where this code is brittle.

Comment 1

3 years ago
I have a patch in progress.  There's some weirdness on B2G I haven't figured out, but also there are a bunch of Mochitest chrome tests that create a new TestAppInfo(), which uses createInstance(Ci.nsIProcess) to spin up a new Gecko instance (I guess?) which gets far enough to create a leak log, but fails to actually write anything to it.

### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmpAi6LZQ.mozrunner/runtests_leaks_default_pid2588.log

It would be nice to know why those processes don't create a leak log.  Also, I guess this means we can't complain when there are multiple default processes, as it seems totally reasonable for a wholly separate Gecko app to be a default process, too.

Comment 2

3 years ago
Created attachment 8491886 [details] [diff] [review]
part 1 - include the pid in default process memory log names. WIP

I figured out why B2G isn't working. hard codes the name 'runtests_leaks.log' for the parent process leak log name, retrieves it from the device into a file with some weird temp name. The weird temp name is easy to fix (and is the immediate cause of the error), but I'm pretty sure that changing the name of the file will break this.

I guess the right solution will be pulling a directory listing off of the device, and then going through things that way.  Ideally that code would be shared with the leak log stuff in automation_utils.

Anyways, for now I think I'm going to ignore this problem.  Dealing with non-hardcoded leak log names will have to be dealt with anyways to deal with content processes, so if that gets fixed, this should be easier to deal with.

Comment 3

3 years ago
Created attachment 8491887 [details] [diff] [review]
part 2 - processType can no longer be None in processSingleLeakFile.

The rest of the patches are just some cleanups that I may be able to factor out in a different way even without part 1.

Comment 4

3 years ago
Created attachment 8491889 [details] [diff] [review]
part 3 - Make the leak log process string include the pid.

Comment 5

3 years ago
Created attachment 8491890 [details] [diff] [review]
part 4 - Fail when we find multiple default process leak logs.


3 years ago
Depends on: 1070068
You need to log in before you can comment on or make changes to this bug.