Open someonewithpc opened 4 years ago
Is this problem reoccurring? When it happens you may find M-x list-processes
useful.
Yes, it happens apparently when I save or switch buffers. list-processes
shows
helm-gtags-u... 17519 run -- /dev/pts/2 global --single-update /home/hugo/software/social/src/Util/Notification/TransportInterface.php
helm-gtags-u... 17901 run -- /dev/pts/3 global --single-update /home/hugo/software/social/src/Util/Notification/TransportInterface.php
helm-gtags-u... 18475 run -- /dev/pts/4 global --single-update /home/hugo/software/social/src/Util/Notification/TransportInterface.php
top
shows:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19532 hugo 20 0 6452 5040 1864 R 99.7 0.0 7:48.90 gtags
20613 hugo 20 0 6452 4976 1800 R 99.7 0.0 2:40.93 gtags
20769 hugo 20 0 6452 5080 1904 R 99.7 0.0 1:53.77 gtags
19531 hugo 20 0 6452 5032 1856 R 99.3 0.0 7:49.14 gtags
20612 hugo 20 0 6452 5048 1872 R 99.3 0.0 2:40.97 gtags
20844 hugo 20 0 6452 5088 1920 R 99.3 0.0 1:35.62 gtags
20845 hugo 20 0 6452 5052 1888 R 99.3 0.0 1:35.18 gtags
The pids don't match because they were taken at different points
So maybe the problem is with helm-gtags
instead? Could also be a global
bug, since the processes seem to not terminate.
$ global --version
global (GNU GLOBAL) 6.6.4
Indeed it may not be ggtags' fault which waits for gtags
to finish before another instance.
So, do you think it's helm-gtags
's fault, or global
's?
I have disabled helm-gtags
and I still get the same problem.
list-processes
global 87804 run *ggtags-def... /dev/pts/1 global --nearness=. --result=grep --path-style=absolute $req
top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87714 hugo 20 0 6584 5040 1872 R 47.5 0.0 3:03.74 gtags
84619 hugo 20 0 6452 5036 1872 R 46.8 0.0 16:14.35 gtags
88210 hugo 20 0 6584 5012 1852 R 46.8 0.0 1:46.60 gtags
85465 hugo 20 0 6584 5060 1884 R 46.5 0.0 12:36.41 gtags
85755 hugo 20 0 6584 5056 1884 R 46.2 0.0 11:05.94 gtags
86472 hugo 20 0 6584 4984 1796 R 46.2 0.0 8:11.66 gtags
87381 hugo 20 0 6584 4996 1824 R 46.2 0.0 4:19.81 gtags
88234 hugo 20 0 6584 5000 1832 R 46.2 0.0 1:43.91 gtags
85809 hugo 20 0 6584 5064 1888 R 45.5 0.0 10:48.74 gtags
86276 hugo 20 0 6584 5080 1904 R 45.5 0.0 8:54.09 gtags
87615 hugo 20 0 6584 5080 1896 R 45.5 0.0 3:17.74 gtags
87804 hugo 20 0 6664 5016 1836 R 45.5 0.0 2:54.65 global
87809 hugo 20 0 6584 5060 1884 R 45.5 0.0 2:53.98 gtags
85616 hugo 20 0 6584 4940 1764 R 45.2 0.0 11:39.59 gtags
86203 hugo 20 0 6584 5072 1892 R 45.2 0.0 9:03.52 gtags
86095 hugo 20 0 6584 4996 1824 R 44.9 0.0 9:40.63 gtags
85998 hugo 20 0 6584 5064 1896 R 42.9 0.0 10:04.90 gtags
Basically it looks like something is starting gtags
without checking existing instances.
You can get the full command of gtags and run it in the terminal to see if it completes its execution. This should tell you if gtags itself is buggy. For example ps ax | grep gtags
may reveal the full command used.
If gtags is working correctly then there may be some elisp program that is at fault. Try to get a minimal example to reproduce the bug. A good start is to start Emacs without loading your customisations.
I'm not sure if this is the result of any recent change, I hadn't updated my packages in a while, but I'm now noticing that about 12 gtags processes get spawned and pin the CPU to 100%. According to
top
, each process uses 80% +/- 20% CPU. If Ikillall gtags
, they come back after a small while. This all happens despite the fact that the entire project is (or appears to be) completely mapped already.The computer is still responsive, but it causes overheating which isn't great in the summer :p