IntelliJ is deleting helpful println and error messages on Debug mode error.
It clears the Debug console and leaves me with:
Execution failed for task ':AutoAuth.main()'.
> Process 'command '/Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/bin/java'' finished with non-zero exit value 1
While the root case of the problem is not clear as the Minimal, Complete, and Verifiable example was not provided, there are several things that can be done to workaround this issue:
See if it runs from the command line Gradle. If it does run, the issue is probably with the JDK or with the way IDE is generating the Gradle script to start it. If it fails, the issue is probably system specific or some wrong Java VM options are used.
JetBrains Runtime bundled with IntelliJ IDEA is not designed for development. As described in the documentation, you should download and install your own JDK to compile and run the apps.
By default IntelliJ IDEA will build and run using Gradle, but this can be changed back to IntelliJ IDEA build/run configurations:
Gradle seem to be really slow for me and I have no idea why.
Whenever I run a build it takes like 30 seconds for me, according to the output 25 seconds of those it's doing nothing.
Building like this:
gradlew build --parallel --offline
This is happening to me now with Kotlin, it was the same when I was using Java only, incremental builds don't seem to do anything either
EDIT: I have the gradle daemon enabled
Every subsequent build right at the start takes as long or longer than starting the daemon apparently doing nothing
This is my Project: https://github.com/forsakenharmony/GameProt
I recommend starting with some measurement:
gradlew build --profile
Open up /report/profile in a web browser and see what it's doing.
It sounds to me like your project is taking a long time to configure. Do you have a large project or many projects in your build? Are you using a bunch of plugins?
The easy way to reduce configuration time is to configure fewer things. Remove plugins that you only use rarely. Try out the #Incubating --configure-on-demand option.
Come back after you've confirmed via profiling for further help.
You can try enabling gradle daemon.
That way gradle won't have to load from scratch every time you start a build. Instead, it will run in background waiting for a build to start.
org.gradle.daemon=true
in «USER_HOME»/.gradle/gradle.properties
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I'm running on Arch Linux, on an i7-5930k 6 core CPU and 64GB of DDR4 RAM, and I'm using IntelliJ IDEA 14.
IDEA was working just fine for me several days ago, but one day, suddenly, it began hanging after opening a project, during the "Indexing" stage. I did not update IDEA and nothing changed about my projects. The IDE's UI hangs after it opens the project, with just a tiny little sliver of the progress bar for "Indexing" complete. Every 5-10 minutes or so it unfreezes and the progress bar crawls forward a little bit, before the IDE freezes again for another few minutes. This happens repeatedly for anywhere between 15 minutes and an hour, until it is finally finished indexing, at which point it hangs for another 5-10 minutes doing nothing, before it finally unlocks and allows me to develop.
While this is happening, my system is fairly unresponsive - Firefox tabs take a long time to switch, and scrolling in them is laggy. Opening a new terminal window takes a long time. Switching windows in general takes awhile. In htop, one of my CPU cores is loaded at 100% while the rest have a normal load, and about 6GB of RAM is used (fairly normal load when this system is idle.)
Things I have tried that have not helped:
Delete caches folder
Delete entire ~/.IntelliJIDEA14 folder
Reinstall IntelliJ package
Download IntelliJ manually from JetBrains' site and run it from my Downloads folder (to see if there was something wrong with the Arch AUR package)
Configure IntelliJ to use my system JVM and Maven for importing instead of its embedded tools
Opening multiple different projects (not just the one I initially experienced the issue on.)
This issue is really hurting my workflow, if anybody has any solution to this I would be very greatful.
Try Invalidating the cache and restarting IntelliJ.
In the File menu, select Invalidate Caches / Restart... and then click the Invalidate and Restart button.
I've finally figured it out. The solution was... Rather odd. TL;DR: Run it under strace. Read on for a more detailed explanation.
I came upon it when I decided to run IntelliJ under strace to see what files it was opening to determine whether or not it was a filesystem bottleneck.
This gave me some very strange results: strace was spewing out a near-constant stream of segfaults. Not only that, but IntelliJ was running just fine, not taking forever to index.
After consulting with a friend, I learned that on Arch Linux, systemd logs a dump of a process's memory every time a segfault occurs, except when a debugger is attached. strace is considered a debugger. Arch was thrashing my disks when it kept logging memory dumps due to all the segfaults, hence why the indexing was taking so long, because it was fighting for disk I/O.
My solution for now is to simply run IntelliJ under strace. I will, however, be looking into the issue further, as I don't think java should be segfaulting that much.
edit Intellij[VERSION]/bin/idea.properties,
set idea.max.intellisense.filesize=50
update:
Intellij will skip index files that size larger than 50kb.try this if you have many libraries or many large files(too many characters one line or too many lines)
I had this issue as well with version 2016.2 on Mac OS X. I had to do a force quit to end the application, then I deleted the .idea folder. The next time I launched IntelliJ everything worked fine, it had no problem indexing the project.
I was stuck with a similar issue with the latest IntelliJ Idea 2019.3, so maybe it'll help. For me the issue was with one of the plugins, uninstalling/reinstalling, cleaning caches didn't help. My steps were:
Kill intellij, start it over
When it's starting and about to load a project, be quick and cancel opening the project. This way you'll end up with a small window with a list of previously opened projects and a few menu items.
Open menu > plugins, disable them all
Restart intellij idea, open any project.
If step 4 above succeeds (which happened to me), one by one try enabling the plugins to see which one is causing error. For me it was Kubernetes plugin from JetBrains.
Select Help -> Debug Log Settings...
Add the following line (note the leading # symbol)
#com.intellij.util.indexing:trace
Relaunch the IDE (don't need to invalidate cache as that will cause it to start from scratch, whereas restarting from the point of failure, for me anyway, reported the problem file as soon as I restarted):
Scheduling indexing of file://C:/dev/tools/ruby/lib/ruby/2.2.0/x64-mingw32/win32ole.so by request of index Stubs
Our project doesn't use win32ole so I moved the file to a safe location and restarted my IDE... Bingo, problem gone, indexing finally completed after almost 1 year of effectively using intellij as a slightly-smarter-than-notepad ruby editor.
In my case I found out that Intellij is actually trying to index a 50GB directory with logs that was under the project's root. Make sure that if you have such a directory, it is marked as "Excluded" in the IDE.
You can see which file the IDE is indexing currently in the Indexing Status window (access by clicking on the indexing message in the toolbar). You may need to enlarge this window to see the full path of the file currently being indexed.
In PhpStorm, what solved this for me was excluding folders I didn't need to be indexed from the indexing (specifically the vendor folder, a caches folder, and a few asset folders that contained thousands of images). Instantly it began making progress and completed.
To do this:
in the project directory list, right click the folder you want to exclude
Mark Directory As
Excluded
seems that there might be several reasons for getting into this "indexing" hell. I spent few hours trying to fix it using the ideas above.
At the end of the day, with some profiling work, I found that the bad guy in my case was the csv plugin:
https://plugins.jetbrains.com/plugin/10037-csv-plugin
I had few (not so large) CSV files serving as input, and although I marked them as not to be indexed, the plugin kept trying to index them.
Once I removed the plugin everything worked fine.
Disabling unused plugins will improve the indexing. In my case I have disabled Kotlin plugin from File -> Settings->Plugins
if you check the intellij logs (can be found under C:\Users<User Name>.IntelliJIdea2019.1\system\log ) you will get a pointer what is failing. I was getting an error in Kotlin. After disabling the plugin and restarting Intellij fixed my issue
java.lang.RuntimeException: java.io.EOFException
at com.intellij.util.ExceptionUtilRt.rethrow(ExceptionUtilRt.java:31)
at com.intellij.util.ExceptionUtil.rethrow(ExceptionUtil.java:120)
at com.intellij.openapi.vfs.newvfs.persistent.FSRecords$DbConnection.handleError(FSRecords.java:516)
at com.intellij.openapi.vfs.newvfs.persistent.FSRecords$DbConnection.access$000(FSRecords.java:153)
at com.intellij.openapi.vfs.newvfs.persistent.FSRecords.writeAndHandleErrors(FSRecords.java:965)
at com.intellij.openapi.vfs.newvfs.persistent.FSRecords.access$300(FSRecords.java:47)
at com.intellij.openapi.vfs.newvfs.persistent.FSRecords$AttributeOutputStream.close(FSRecords.java:1629)
at kotlin.io.CloseableKt.closeFinally(Closeable.kt:53)
at org.jetbrains.kotlin.idea.caches.FileAttributeServiceImpl.write(FileAttributeServiceImpl.kt:64)
at org.jetbrains.kotlin.idea.caches.FileAttributeServiceImpl.writeBooleanAttribute(FileAttributeServiceImpl.kt:48)
at org.jetbrains.kotlin.idea.caches.IDEKotlinBinaryClassCache.getKotlinBinaryClass(IDEKotlinBinaryClassCache.kt:67)
at org.jetbrains.kotlin.idea.caches.IDEKotlinBinaryClassCache.getKotlinBinaryClassHeaderData(IDEKotlinBinaryClassCache.kt:8
I had a similar problem with 2019.1.4. However, mine would change directories and sometimes, eventually, finish. If it did finish, it was somewhere in the 8-10 minute range.
I was all over SO, and even JetBrains' forums. I excluded directories via Project Structure | Modules. I used Invalidate Caches And Restart on multiple occasions. I tried having only 1 project open to let it finish. I installed and tried 2019.2.4 and 2019.3.3 (the latter would crash for other reasons). And best of all, it only seemed to happen on one project!
What ultimately led me to an answer was Help > Activity Monitor... where I found psi.impl.cache.impl.todo was running at nearly 100% CPU and not showing signs of stopping.
It turned out, I had a TODO filter setup with a poorly-defined RegEx. It was something like \b.*wip\b.*; the idea was to find all of our "WIP" values. Well, the leading .* was a huge mistake and one that didn't occur to me until losing many hours blaming a plugin upgrade. I believe the reason this was a bad filter was because the project it was hanging on is in ExtJS, which is JavaScript, which means things are in triplicate with the app.js file and whatnot...
Update
In IntelliJ 2020.x and 2021.x, the option has moved to Help > Diagnostic Tools > Activity Monitor.
Had the same issue in the past on some Scala project. I have installed IDEA 16 EAP (https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP) and the problem has gone.
I ran into this problem today on a Mac. It would hang before I was able to get to the menu and invalidate the cache.
I deleted the cache from command line using the following command and it worked for me.
rm -rf ~/Library/Caches/JetBrains/IntelliJIdea*
After that it started up with no issues.
I had the same problem with IntelliJ 2017.3.2. When I clicked on the indexing progress bar I noticed it was hung on a directory within my build directory. When I did a gradlew clean which removed that directory then the indexing was able to proceed.
I have encountered this problem, and resolved it:
remove idea
delete all files and dirs which name regex 'jetbrain' and 'IntelliJ' in my computer(Mac mini)
then install idea
I also try just delete idea cache files, it do not work.
I was using the Elm plugin and installed the elm-bounded-nats package which included a semi-large source file. IntelliJ kept hanging on this file, but did not always report this correctly in the indexing popover dialog (perhaps due to threading). When I exluded this specific file in Settings -> File Types ("Nats.elm") indexing managed to complete successfully. Now the editor renders errors for this package but the compilation process still works.
Invalidate Cache and Restart did not work for me on IntelliJ 2021.3 Ultimate.
I was curious to see if the new Repair IDE feature on 2021.3 Ultimate version works on this issue on my mac.
On startup, IntelliJ froze on indexing
Force quit and relaunched IntelliJ
On Startup, manually "paused" the indexing from the status bar at the bottom
Invalidated cache and restarted
Still froze on indexing
Forced quit and relaunched IntelliJ
Repeated Step #2 on startup
From File Menu, executed Repair IDE, and went through repair steps
FIXED; no longer froze on indexing
Quit IntelliJ and Relaunch
No Index issues
I was also facing freezing issue with intellij 2021.3. Earlier I was using intellij 2021.1 version and that was working fine but since I upgraded intellij version to 2021.3 it started freezing on indexing of files.
Someone in this thread suggested to repair ide using Repair IDE feature. But that didn't worked for me.
So, I went through the thread dumps available in intellij logs folder. After analyzing logs, I found out that calls are blocking on Package Search plugin. So, I disabled that plugin in settings -> plugin. To do that I had to pause indexing at start for time being. After disabling this plugin, it is working fine for me.
This is a known issue and I know disabling it is not a correct fix for it. But I will use it till intellij will release an official fix for this issue.
There might be another project opened parallelly in new window which is being indexed.
It looks like the problem can come from many different sources as other answers point out.
In my case, it was the Subversion plugin that had difficulties to communicate with the server and make the IDE to hang on indexing.
I was able to resolve this problem by removing all of my "target" folders from my project.
I am using IntelliJ 13.1 on Linux and try to build a basic REST application following the example http://spring.io/guides/gs/spring-boot/
When I execute the target bootRun from within IntelliJ the intergrated tomcat server is started and everything works fine.
10:09:35: Executing external task 'bootRun'...
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:findMainClass
:bootRun
But stopping the execution does not affect the gradle task:
10:11:40: External task execution finished 'bootRun'.
I still can access the tomcat instance on the configured port. Only closing IntelliJ will destroy the process.
I searched on this topic but could not find any reasonable answers. I wonder if it is a
gradle problem (using gradle wrapper version 1.11)
Linux problem (Ubuntu 12.04)
IntelliJ problem (IDEA 13.1.2)
Spring Boot problem (tried different versions from 1.0.0.RELEASE to 1.1.0.M2)
I am pretty sure it's an IntelliJ issue because:
When you run the bootRun from IntelliJ's Gradle integration and then press stop, the application continues to run as you mentioned.
However, if you use the command line and run gradle bootRun and then use Cntrl+C, the application stops just fine.
Note that my setup is Windows 7, IntelliJ 13.1.3, Gradle 1.12 and Spring Boot 1.1.0.M2.
If your need to is to be able to easily debug your application, all you need to do is run the Java (or Groovy) Class that has the main method, since that it is the easiest way to run Spring Boot applications! Kudos to Spring Boot for that!!!
Of course you can continue to use Gradle for tasks like running all the tests or creating the packaged application.
It's may not perfect solution. But for a quick fix, it will help you.
Goto terminal and apply this command to terminate the process
sudo kill -9 `sudo lsof -t -i:8080`
Note: Replace your port number instead of 8080
I know this answer was already answered, but as this is first topic when searching in Google, I thought in sharing an alternative I went with and didn't find in other topics I read.
My main problem with this terminate was that always I changed something in my classes, I needed to restart the server, and it would fail so I needed to stop/start the server sometimes.
To avoid this, I use spring-boot-devtools. Basically:
Applications that use spring-boot-devtools will automatically restart whenever files on the classpath change.
The only catch is that on Intellij it only makes the project if click Build > Make Project, so either set it to build automatically or remember to click on make.
To use, simply add the dependency to your build.gradle / pom.xml:
compile('org.springframework.boot:spring-boot-devtools')
I found this to be really useful in development.
I am using IntelliJ in Mac, running Spring boot application was giving the same issue. Whenever I run the app in Terminal and use CTRL + Z, the terminal will strop running the app. But when I run the app again in the same terminal, will give error saying the port 8080 was in use.
I just tried the option to close the Terminal session ( right click -> select -> Close Session). This will close the terminal, and when I clicked the terminal option again and ran the app, it ran smoothly.