Open
Bug 1068869
Opened 10 years ago
Updated 2 years ago
Default process logs created by InitLog should contain the pid
Categories
(Core :: XPCOM, task, P3)
Core
XPCOM
Tracking
()
NEW
People
(Reporter: mccr8, Unassigned)
References
Details
Attachments
(4 files)
4.10 KB,
patch
|
Details | Diff | Splinter Review | |
2.74 KB,
patch
|
Details | Diff | Splinter Review | |
2.29 KB,
patch
|
Details | Diff | Splinter Review | |
1.16 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•10 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.
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Comment 3•10 years ago
|
||
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.
Reporter | ||
Comment 4•10 years ago
|
||
Reporter | ||
Comment 5•10 years ago
|
||
Reporter | ||
Comment 6•5 years ago
|
||
This is probably still technically a good idea, but I don't remember multiple parent processes being a big issue for leak checking.
Assignee: continuation → nobody
Type: defect → task
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•