[Bug]: 100% CPU Usage

[OceanOC]

What happened?

Why is codelite using 100% CPU usage constantly

OS: Arch Linux

Screencast_20240610_221706.webm

Version

Self compiled

Operating system

Linux

Steps to reproduce

Use yay to download codelite-unstable from the AUR repository
Run codelite-unstable

Relevant log output

No response

[OceanOC]

It seems like the Language Server Plugin is doing this for some reason. Though this only spikes when a project is loaded

[eranif]

Can you try and attach gdb to CodeLite and then hit Ctrl-C? once gdb breaks, print the backtrace. If you can do this multiple times and see a repeating pattern - we will probably have our culprit

Thanks!

[OceanOC]

This was the most common #0 0x0000772e1d1278f7 in select () at /usr/lib/libc.so.6 2nd most common #0 0x000071a07bf1c9ba in read () at /usr/lib/libc.so.6

Following your steps i got these, I don't use gdb much so I don't know if this is of any relevance.

[eifrah-aws]

please paste more than 2 lines... (after you stopped CodeLite with Ctrl-C type bt to get the full backtrace)

[OceanOC]

That was all i got from bt after pressing Ctrl-C from the Code Lite process that was using 100% CPU

This is from the Code Lite process which was using very little CPU Backtrace

[eifrah-aws]

You are probably getting only backtrace from a single thread. Try getting all the threads (for the 100% CPU process):

instead of bt use this command thread apply all bt

[OceanOC]

The Backtrace

[eranif]

This backtrace is lacking. CodeLite is multi-threaded application with many thread. This backtrace shows, basically one of the threads doing "select" syscall. This tells me 2 things:

• This is not the threads we are looking ("select" means that the thread is suspended)
• This is not the main thread

Did you run thread apply all bt ? this should show ALOT more threads

[OceanOC]

That was from the 100 CPU thread, This is from one of the 0 CPU ones

[eranif]

Making sure I understand:

From the CodeLite that consumed 100% you got this backtrace only:

Thread 1 (Thread 0x7c7dd7e006c0 (LWP 2180) "codelite"):
#0  0x00007c7dfcf278f7 in select () at /usr/lib/libc.so.6
#1  0x00007c7dfd5b86d5 in UnixProcess::ReadAll (fd=29, content="", timeoutMilliseconds=<optimized out>) at /usr/src/debug/codelite-unstable/codelite-17.10.0/CodeLite/UnixProcess.cpp:103
#2  0x00007c7dfd6b6790 in UnixProcess::StartReaderThread()::{lambda(UnixProcess*, int, int)#1}::operator()(UnixProcess*, int, int) const [clone .isra.0] (process=0x5a8cdf4e3630, stdoutFd=29, stderrFd=27, __closure=<optimized out>) at /usr/src/debug/codelite-unstable/codelite-17.10.0/CodeLite/UnixProcess.cpp:196
#3  0x00007c7dfd0e0c84 in std::execute_native_thread_routine (__p=0x5a8cdf4dd000) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#4  0x00007c7dfcea6ded in ??? () at /usr/lib/libc.so.6
#5  0x00007c7dfcf2a0dc in ??? () at /usr/lib/libc.so.6

?

[OceanOC]

Yes that was all i got since there's only 1 thread that takes up 100% of the CPU

[eranif]

This is wrong. This thread is not even the main thread, so we should see here at least one more thread and this thread is suspended so it can't be taking 100% CPU

[OceanOC]

When gdb starts the thread becomes suspended and once gdb is closed is goes right back to 100% CPU, there is about 8 or so threads on ~0.6% CPU which I am guessing are the main threads

[OceanOC]

It seems the Rust analyzer is the problem which is causing 100% CPU usage. This probably isn't an Codelite issue then