GJS profiler immediately stops when analyzing gnome-shell
System information
This problem is affecting a workstation environment running Red Hat Enterprise Linux 7.6. We are using gjs-1.52.3, mozjs52-52.9.0, and gnome-shell-3.28.3.
The same problem happens on my laptop running Fedora 29. Relevant components are gjs-1.54.3, mozjs60-60.4.0, and gnome-shell-3.30.2.
Bug information
Steps to reproduce
- Stop GDM (for example, with systemctl stop gdm.service)
- Launch X from a TTY and spawn an xterm window
- Run the following command:
GJS_ENABLE_PROFILER=1 gnome-shell
- Use ps to identify the PID of gnome-shell
- Observe that gjs-PID.syscap is created in your home directory, as per #31 (closed)
Current behaviour
A message Gjs-Message: Profiler started appears in the output of the gnome-shell command, but is soon followed by Gjs-Message: Profiler stopped. Likewise, the gjs-PID.syscap file is created successfully, and inspecting it with Sysprof shows that Javascript method calls are being successfully captured, but there are very few such calls listed in the file. Most of them seem to be associated with shell extensions, though there a few items (like "gnome/shell/ui/windowManager.js") which sound more important. The file stops growing only a few seconds after the launch of GNOME Shell and never gains additional entries.
Expected behaviour
I am hoping to use the GJS profiler to isolate the cause of an unusual performance issue in GNOME Shell, which does not appear to have been reported previously. I was excited to read about the GJS profiler, and even more excited to see that #31 (closed) made it easy to use from GNOME Shell. I suspect that the profiler should not be stopping so quickly, based on a few observations:
- GNOME Shell, to the best of my understanding, makes heavy use of Javascript at all times. This is evident from the huge amount of JS code inside GNOME Shell and also from the fact that attaching gdb to a running instance — even long after the profiler has stopped — will frequently reveal a backtrace somewhere in the middle of the SpiderMonkey interpreter.
- The same JSContext is (probably) used continuously throughout GNOME Shell's lifetime. I launched GNOME Shell with gdb and identified the address of the JSContext initialized during gjs_context_constructed, and then compared it against the address of a JSContext obtained from a later backtrace (the same one I mentioned in the first bullet point). The addresses were identical, and so I would expect the profiler settings from earlier to have persisted.
If the profiler continued to collect information about fundamental GNOME shell actions, like window management and refreshing the screen contents, then I would be in a much better place to continue debugging the performance issue I mentioned. Thanks for any assistance you can provide.