CLion hang "scanning files to index" on Ubuntu 15.04 when opening project
Is anyone hitting a weird hang with CLion 1.0.1 on Ubuntu 15.04 where it hangs a couple seconds after opening a project? The taskbar says "two tasks" and "scanning files to index" but the whole thing becomes unresponsive. Even more fun is that it causes *other* tasks and windows to become similarly unresponsive. For example, if I start up a terminal while it's doing this and try to run top or ps, that window will hang as well. However, I can connect from another machine via SSH and don't have any problems killing the task.
It works fine at home (Ubuntu 14.10). I'm not sure if this started after I updated or not, since I also just put the newest CLion on here.
Please sign in to leave a comment.
Just updated to 1.0.2... No difference. :(
Jack, could you please attach a log file (Help | Show Log) and take a thread dump using 'jstack <clion_pid>' command line?
Sure can't! :)
CLion hangs about two seconds after it opens a project, so I can't get the log. I attempted jtrace and got:
$ jstack 6191
6191: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
$ jstack -F 6191
Attaching to process ID 6191, please wait...
Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
[...omitted rest since it's not from clion and probably not relevant]
Since it's causing other programs on my desktop to hang, I figured doing a stack trace on them might give some hints as well. Here's two of Firefox. The first is after its' stalled and unresponsive. The second is right after I start clion but Firefox is still accepting input:
$ sudo strace -p9118
Process 9118 attached
restart_syscall(<... resuming interrupted call ...>) = 1
read(25, "\372", 1) = 1
futex(0x7fa4a3ddbf0c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7fa4a3ddbf08, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
recvmsg(4, 0x7ffd26784940, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=39, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(4, 0x7ffd26784940, 0) = -1 EAGAIN (Resource temporarily unavailable)
$ sudo strace -p9118
Process 9118 attached
restart_syscall(<... resuming interrupted call ...>) = 1
read(25, "\372", 1) = 1
recvmsg(4, 0x7ffd26784940, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=39, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(4, 0x7ffd26784940, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=24, events=POLLIN}, {fd=25, events=POLLIN}, {fd=39, events=POLLIN}], 5, 0) = 0 (Timeout)
recvmsg(4, 0x7ffd26784940, 0) = -1 EAGAIN (Resource temporarily unavailable)
My guess is that CLion is doing something unfriendly with some shared resource that everything else in a desktop session is trying to access. Not quite sure what that'd be, though.
Updated to 1.0.3, still hangs.
I noticed that it reports 2 tasks running and has spawned two instances of cmake with what look to be bogus values:
/usr/local/clion-1.0.3/bin/cmake/bin/cmake -DCMAKE_BUILD_TYPE= -DCMAKE_ARCHIVE_OUTPUT_DIRECTORY= -DCMAKE_LIBRARY_O[...rest cut off]
It didn't seem to re-run the cmake processes the second time around. I did try telling it to not use the pack-in version of cmake but didn't see a difference. Also turned off the code inspector.
Ok, cat /proc/<java pid>/stack tells me that when it hangs, its stuck on futex_wait_queue_me. There was a kernel bug that relating to futexes that was fixing for 3.18 (I'm on 3.19 so in theory have it). As a test, I forced the thing to run on a single core using taskset. When I pin it to a single execution core, it dosn't hang.
So this looks like it's having some problem synchronizing via futex. I'm not sure what it's trying to lock but it's something that a) causes a hang when it's allowed to run on multiple cores and b) takes down a lot of other processes with it. For now, I'll work around it by starting CLion like this:
taskset 0x8000 ./clion.sh
Which will tell it to only schedule it on core #15. Not a great workaround, obviously, but at least I can do some work now.
Hi Jack.
Could you please specify which JDK version do you use?
Also please compare JDK version on the problem environment with the good one.
Could you please try to use another JDK version?
I am having the same problem after i updated Ubuntu from 14.04 to 15.04 (fresh installation).
I'm using Intellji Idea instead of Clion and the whole IDE hangs a few seconds after opening a project.
Edit: using taskset 0x800 ./idea seems to aleviate the issue, but since the whole ide then runs just on one core, everything is much slower compared to then I used ubuntu 14.04. The same issue happens with Oracle 8 JDK and OpenJDK 8.
I also am experiencing this issue in both Android Studio and IntelliJ IDEA. It started after upgrading from Ubuntu 14.04 to 15.04, and continued with a clean install of 15.04. I've tried Oracle and OpenJDK 7 and 8, and experience this with all of them.
Hi Alex.
We have the issue in the tracker:
https://youtrack.jetbrains.com/issue/WEB-16483
As a result of investigation - it seems to be caused by Linux kernel problems.
Some solution which may improve your experience is to start the process using taskset (e.g.,
taskset 0x800 ./idea.sh
– the value of the mask is dependant of your processor configuration).Feel free to add your comments under the issue.
This bug still persists on both the latest IntelliJ Idea and CLion, on linux kernel version 4.2.0-22.
As some people pointed out, this seems to be Linux kernel bug. However, I've noticed that it only triggers when dual booting.
1. If I turn on my PC, boot linux and then start CLion, everything works perfectly.
2. However if I turn on my PC, start windows (8.1), reboot to linux and then start CLion/Idea, the IDE hangs 100% of times.
3. If I turn on my PC, boot linux, start CLion, reboot, boot windows, reboot, boot linux and start CLion/Idea it hangs again.
In other words, booting windows seems to affect computer's state in such a way that it causes idea to hang on futex_wait_queue_me in linux.
If anybody still experiences this bug, I'd like you to test this and to confirm or deny this finding.
I dual boot linux (gentoo) and Windows 10. This happens to me too.
I've straced it and found problems with accessing a futex. It definitely seems kernel related.
What I've found is that it persists through reboots. The only way for me to "fix" it is to actually completely power off the computer and then when I boot back into linux it works.
What kind of motherboard & cpu do you have?
I use Asus P9X79 deluxe with Intel i7-3930k.
Eggggh... ok, so to recap:
1) There is some bad mojo which results in a livelock around the use of a FUTEX in "certain circumstances."
2) So far, the only reports have been with newer Intel CPUs.
3) Some state is being retained between warm reboots affecting this, even with different operating systems.
That third one there is worrisome, since "that shouldn't happen." I wonder how FUTEX is being implemented; I imagine some cases would make use of special CPU instructions for speed, maybe there's a bug either in how FUTEX is implemented in Linux with regard to those processors or something weird happening in the CPU itself. I'll poke around in the kernel when I get a chance and see if anything looks jenkity.
Is anyone seeing this outside of the fancier Intel chips?
- Jack
Yea my CPU is an i7-5820K, motherboard is an MSI Gaming-7.
Luckily this problem doesn't present itself much as when I reboot to Windows it's just to play games at the end of the night and then I power off. So when I go to work the next day my linux starts from a cold boot.
Agreed that it has to be some weirdness in how the kernel implements futexes, some asm instruction that newer chips don't handle well. Who knows though. I'm content just having found a work around. For a while I was scared I wouldn't get to use clion any more. :)
Edit: one more thing, this may or may not have any effect on the cause but I am running my CPU overclocked, albeit only slightly but OC'd none-the-less. That may have something in common with others having this issue. It is a really small OC though and has been super stable with everything even extended builds using 12 jobs, so pegs all 6 cores for a very long time. Just thought I'd mention it in case it might be a common thread.
No, I'm not overclocking.