Today I upgraded IDEA to latest 7 EAP build and again I was faced with a
symptom that I experienced before. The SVN Changes updating takes forever
and consumes 100% CPU. I decided to track this problem down once and for
When the Netbeans profiler couldn't help me (the JVM running IDEA constantly
froze when attaching profiler to it) I tried a different approach that
saved me before. The "Ctrl-\" (aka SIGQUIT) is a life-saver when it comes
to figuring out what's happening with the program...
The thread dump revealed a suspicious thread called "Change List Updater"
which was just executing some external process. Investigating further I
found that IDEA was spawning external processes "ls -ld some/file" at a
rate about 50 times per second. At this point I knew what was causing the
100% CPU but I didn't know why.
Luckily the code responsible for this was from an open source
library "javasvn.jar" that comes with source code. If it was from IDEA
internal codebase I couldn't track this down without resorting to "illegal
activities" in the form of "jad" or something similar.
The problem that the sources revealed was actually the problem of Sun's JNA
library (https://jna.dev.java.net/) which was not being used due to not
being able to load it's native part due to SELINUX preventing to load a
shared object file from /tmp directory when not having appropriate SELINUX
permissions (The JNA library extracts appropriate shared object file from
it's resources to the /tmp directory and tries to load it from there).
Javasvn library not being able to use JNA falls back to using an inefficient
method of figuring out whether a file is a symbolic link or not - by
spawning external process "ls -ld file" and parsing it's output.
That's why. Now, how to fix it? Since I never use symbolic links in my SVN
trees and javasvn library offers an option to not detect them I choose to
add the following line to "idea.properties":
I can sleep peacefully now.