1068869 - Default process logs created by InitLog should contain the pid

Status: NEW

(Core :: XPCOM, task, P3)

Description

[Andrew McCreight [:mccr8]]

InitLog includes the pid for non-default processes, creating logs with names like:
  runtests_leaks_tab_pid50776.log
For a default process, it does not do that, giving log names like:
  runtests_leaks.log
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:
  runtests_leaks_default_pid50776.log

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

[Andrew McCreight [:mccr8]]

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

[Andrew McCreight [:mccr8]]

Attachment: part 1 - include the pid in default process memory log names. WIP

I figured out why B2G isn't working.  runtestsb2g.py 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

[Andrew McCreight [:mccr8]]

Attachment: 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

[Andrew McCreight [:mccr8]]

Attachment: part 3 - Make the leak log process string include the pid.

Comment 5

[Andrew McCreight [:mccr8]]

Attachment: part 4 - Fail when we find multiple default process leak logs.

Comment 6

[Andrew McCreight [:mccr8]]

This is probably still technically a good idea, but I don't remember multiple parent processes being a big issue for leak checking.