GJS profiler immediately stops when analyzing gnome-shell
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.
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:
- Use ps to identify the PID of gnome-shell
- Observe that gjs-PID.syscap is created in your home directory, as per #31 (closed)
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:
- 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.