GPU process is sometimes not captured in profiles
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
People
(Reporter: jrmuizel, Unassigned)
References
Details
This seems to happen to me and others fairly often. I don't know how to reproduce it on demand.
I think it's a duplicate of bug 1529131.
And it may be a similar issue as seen in bug 1737058, and could be fixed by bug 1638236 (better handling of slow child processes).
It seems to be happening more these days, so I'll bump the priority on these bugs, and try to work on them soon.
|
||
Comment 2•3 years ago
|
||
So your hypothesis is that it only happens if the profile is captured after the GPU process exited? I'm not sure if that's the case.
(In reply to Markus Stange [:mstange] from comment #2)
So your hypothesis is that it only happens if the profile is captured after the GPU process exited? I'm not sure if that's the case.
Oh, I see that was the main hypothesis in bug 1529131. I marked this bug here as duplicate based on just the bug title "Shutdown profiles should include profiles from all child processes", which is more generic.
Another hypothesis I'm thinking of is that the main process doesn't wait long enough for some busy processes to send their profile.
In any case, this needs more debugging and logging, and I intend to work on this whole profile-capture business in bug 1638236 (this quarter if possible, or next one for sure), where the parent process would conduct a continuous IPC dialog with each sub-process to make sure things are progressing. And then if that doesn't just fix this issue we'd hopefully have more information to better understand what is happening in the wild (whether the GPU process is somehow forgotten, or it doesn't respond, etc.)
In the meantime, if you think this bug here is not really a duplicate of bug 1529131, feel free to reopen it.
|
|
||
Comment 4•3 years ago
|
||
(In reply to Gerald Squelart [:gerald] (he/him) from comment #3)
Another hypothesis I'm thinking of is that the main process doesn't wait long enough for some busy processes to send their profile.
Is there a way to test this hypothesis? Is there a pref for the wait time?
There is a pref to add a number of seconds of wait time: "devtools.performance.recording.child.timeout_s" (default 1s).
My hypothesis is based on seeing actual times when profiling a specific child process, the parent process took a handful of milliseconds to do its own work (normal because there should be almost nothing to store), and the targeted process took more than 10 seconds!
I'm hoping bug 1638236 will both prove it and fix it, or in the worst case at least give more actual information about what's happening...
Description
•