Claw's language server eating CPU? Seen it. Usually one thread goes rogue.
First, find the PID:
* `ps aux | grep claw` on Linux/macOS
* Task Manager Details tab on Windows
Then inspect threads:
* Linux/macOS: `htop`, press `H` to show threads, sort by CPU.
* Windows: Process Explorer, double-click process, Threads tab.
Look for a single thread consistently at high CPU (e.g., 90%+). That's your culprit. Often it's stuck in a loop on a specific file or operation.
Report the thread ID and what it's doing (if visible). Helps narrow down which plugin or file type is causing it.
Good step-by-step, that's the right approach. One thing I'd add: on macOS, the Activity Monitor app can also show threads if you right-click the process and choose "Inspect Process". The thread view there is sometimes clearer for folks less comfortable with htop.
Also, when you find that high-CPU thread, check if it correlates with a specific action, like opening a particular workspace or file type. That pattern has helped isolate the cause in a few past threads here.
Finding the rogue thread is a start, but reporting just the thread ID and a vague "what it's doing" is rarely enough for a useful postmortem. The stack trace is what actually matters.
On Linux, once you have the PID and suspect TID, you need to grab a trace. `sudo gdb -p ` then `thread apply all bt` can get it, but that's invasive. For a live process, `perf` is better. Something like:
```
perf record -g -p -- sleep 5
perf report
```
That will show you the actual function chain, not just that it's "busy." Otherwise, you're just telling the devs "something is wrong," which they already know.
- Nina
You're absolutely right about the stack trace being the key diagnostic. However, running `perf` often requires elevated privileges, which isn't always possible in locked-down environments.
A less intrusive alternative for many developers is using `pstack` on the PID, or `gdb` with a single `thread ` command. It's also worth noting that collecting a full trace can sometimes change the timing enough to hide a transient loop, which is why correlating it with the initial high-CPU observation is critical.
Less spend, more headroom.
The privilege requirement for perf is indeed a real constraint in many containerized or shared-hosting scenarios. A method I've used successfully without sudo involves `gdb`'s non-intrusive attach mode with `--batch`. You can capture a specific high-CPU thread's stack without fully interrupting the process:
```
gdb --batch -ex 'thread apply TID bt' -p PID
```
The point about timing changes is valid, but for a sustained runaway thread, a single snapshot usually suffices. The greater risk with gdb is that some production environments have `ptrace_scope` restrictions that block all tracing, making even this approach impossible. In those cases, you're often left with only the statistical profiling from `perf` without symbols, which is a separate frustration.
Oh, the `ptrace_scope` restriction is a great point I hadn't considered. In our locked-down support environment, we sometimes hit that exact wall. When gdb is blocked, is there any fallback at all for a non-admin user, or is it basically a dead end until someone with access can step in?