[go: nahoru, domu]

Open Bug 1529131 Opened 6 years ago Updated 28 days ago

Shutdown profiles should include profiles from all child processes

Categories

(Core :: Gecko Profiler, defect, P1)

defect

Tracking

()

ASSIGNED
Tracking Status
firefox67 --- affected

People

(Reporter: mozbugz, Assigned: canova)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fxp-profiler])

Attachments

(5 files, 1 obsolete file)

Follow-up to bug 1509533, which added Web Content process profiles to shutdown profiles.

But Markus remarked in https://phabricator.services.mozilla.com/D20277#545829 :

However, this reminds me that we only have "exit profiles" for content processes, but not for other processes such as the GPU process, the network process or the decoding process. And if I remember correctly, sending up the exit profile and shutting down the PProfiler protocol correctly required some fragile back-and-forth communication that we may not want to do for the other processes. So this approach is inferior to the approach you suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=1528859 in that sense. Not having a useful Compositor thread in shutdown profiles on Windows may be quite painful.

Could other processes automatically send exit profiles?
Should we attempt to make them send an exit profile when the main process knows shutdown is happening?

Priority: P1 → P3

(In reply to Gerald Squelart [:gerald] (he/him) from comment #0)

Could other processes automatically send exit profiles?
Should we attempt to make them send an exit profile when the main process knows shutdown is happening?

I think this would be the right thing to do. Maybe it's not actually that hard.
I have forgotten everything about PProfiler and the challenges involved in coordinating shutdown.

I'm guessing you're commenting now because of my recent activity on bug 1528859. 😁
It would certainly be nice to fix this bug here anyway, but I don't know enough either to ascertain how difficult it would be.

Regarding the other bug (each process writes its own shutdown file at the last possible moment, and they can then be combined), I already have a quick fix I worked on on the side months ago, so I'm just pushing it over the line in case some people find it useful.
Also, looking at a test profile in bug 1528859 comment 6, that solution actually outputs a bit more data from sub-processes, so I think it's got its own extra value anyway, whether we fix this bug here or not.

This seems to happen more frequently these days, so I'm increasing the priority.
I believe bug 1638236 should help.

Assignee: nobody → gsquelart
Severity: normal → S3
Type: enhancement → defect
Depends on: 1638236
Priority: P3 → P2

Is this still happening? Recent experiences welcome.

Note that we now have a log that may help:
When viewing the profile in https://profiler.firefox.com, open the web dev tools, go to the Console, and type profile.profileGatheringLog. It should print an object with one entry being the PID of the parent process, which contains a list of events.
If you think a process is missing, please check these events for clues, and/or share them here.

Assignee: mozbugz → nobody
Whiteboard: [fxp-profiler]
Assignee: nobody → canaltinova
Status: NEW → ASSIGNED
Priority: P2 → P1
Blocks: 1863615

This seems to have been approved a year ago. Is it still viable? What was/is blocking it from landing?

Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(canaltinova)

I think we need to verify the shutdown sequence, and I forgot and nobody screamed at me :'(. Nazim, can you rebase and fix all the clang-tody lints?

Flags: needinfo?(lissyx+mozillians)

Ah yeah I think Markus had asked Nika to get some more help from her. But then we forgot to follow-up. It would be great if you can help! I'll do that soon and will let you know.

Flags: needinfo?(canaltinova)
Attachment #9332662 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: