I'm using Intellij 13.1.5 on Ubuntu 14.0.4 (amd64), Maven 3.0.5, Java Oracle 1.7.0_72
I noticed some irregularities with maven whilst using Intellij namely dependencies added and removed where not reflected in the module or in the External Libaries listing.
Then when I ran Intellij from the shell I saw this exception:
[ 14649] WARN - #org.jetbrains.idea.maven - Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
org.jetbrains.idea.maven.indices.MavenIndexException: Cannot open index /home/sbotting/.IntelliJIdea13/system/Maven/Indices/Index0
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:164)
at org.jetbrains.idea.maven.indices.MavenIndex.<init>(MavenIndex.java:139)
at org.jetbrains.idea.maven.indices.MavenIndices.load(MavenIndices.java:59)
at org.jetbrains.idea.maven.indices.MavenIndices.<init>(MavenIndices.java:47)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureInitialized(MavenIndicesManager.java:107)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.getIndicesObject(MavenIndicesManager.java:91)
at org.jetbrains.idea.maven.indices.MavenIndicesManager.ensureIndicesExist(MavenIndicesManager.java:164)
at org.jetbrains.idea.maven.indices.MavenProjectIndicesManager$3.run(MavenProjectIndicesManager.java:120)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:320)
at com.intellij.util.ui.update.MergingUpdateQueue.execute(MergingUpdateQueue.java:310)
at com.intellij.util.ui.update.MergingUpdateQueue$2.run(MergingUpdateQueue.java:254)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:269)
at com.intellij.util.ui.update.MergingUpdateQueue.flush(MergingUpdateQueue.java:227)
at com.intellij.util.ui.update.MergingUpdateQueue.run(MergingUpdateQueue.java:217)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.Alarm$Request$1.run(Alarm.java:327)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:298)
at com.intellij.util.concurrency.QueueProcessor$RunnableConsumer.consume(QueueProcessor.java:295)
at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:419)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.java:149)
Caused by: java.lang.RuntimeException: Cannot reconnect.
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:111)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.createIndex(MavenIndexerWrapper.java:61)
at org.jetbrains.idea.maven.indices.MavenIndex.createContext(MavenIndex.java:305)
at org.jetbrains.idea.maven.indices.MavenIndex.access$500(MavenIndex.java:40)
at org.jetbrains.idea.maven.indices.MavenIndex$IndexData.<init>(MavenIndex.java:611)
at org.jetbrains.idea.maven.indices.MavenIndex.doOpen(MavenIndex.java:185)
at org.jetbrains.idea.maven.indices.MavenIndex.open(MavenIndex.java:161)
... 33 more
Caused by: java.rmi.RemoteException: Cannot start maven service; nested exception is:
com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:124)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:65)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:387)
at org.jetbrains.idea.maven.server.MavenServerManager$5.create(MavenServerManager.java:383)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(RemoteObjectWrapper.java:41)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.getRemoteId(MavenIndexerWrapper.java:159)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper.access$100(MavenIndexerWrapper.java:37)
at org.jetbrains.idea.maven.server.MavenIndexerWrapper$1.execute(MavenIndexerWrapper.java:64)
at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(RemoteObjectWrapper.java:105)
... 39 more
Caused by: com.intellij.execution.ExecutionException: -Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xdiag show additional diagnostic messages
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-XshowSettings show all settings and continue
-XshowSettings:all
show all settings and continue
-XshowSettings:vm show all vm related settings and continue
-XshowSettings:properties
show all property settings and continue
-XshowSettings:locale
show all locale related settings and continue
The -X options are non-standard and subject to change without notice.
at com.intellij.execution.rmi.RemoteProcessSupport.acquire(RemoteProcessSupport.java:142)
at org.jetbrains.idea.maven.server.MavenServerManager.create(MavenServerManager.java:121)
... 48 more
I've tried deleting the ~/.IntelliJIdea13/system/Maven/
with no result
My M2_HOME is properly set to /usr/share/maven
I assume that the solution lies in finding the underlying cause for the ExecutionException although the diagnostic doesn't really help with this.
I've tried reverting back to Intellij 12.0.4 and it works fine (in terms of Maven - although sadly it doesn't support svn 1.8)
also the output seems to come from the java -X command which gives you a printout of all the -X options
Any suggestions?
I had this problem all of a sudden (after an update + Windows Update). I tried a lot of things, and in the end, set Settings > Build, Execution, Deployment > Build Tools > Maven > Importing > JDK for Importer to Use JAVA_HOME (which I've set up as an env var pointing to a JDK install). That seems to work.
Go to file and select the project from the menu structure.
Then change the JDK version form the list of JDKs.
In the Settings > Maven > Importing in box for "VM options for importer:" box I had -Xmx512m -X
for some reason there was a loose -X I removed that and everything is now working fine.
My hosts file lack of the line:
127.0.0.1 localhost
lead to this problem.
I had this issue and it was due to me changing the JDK for importing in Intellij
I changed it from using internal JRE to java 1.8.0_74
I changed this back to use the Internal JRE of intellij and it worked.
Didn't need to change anything with my .m2 settings
Related
Seems that the new release by default starts the Embedded Mongo when it's found on the classpath instead of using the mongo template defined in the application.properties.
The workaround is to temporary remove flapdoodle.embed from the dependency list even if it's in test scope
2020-06-24 09:22:53.048 INFO 51028 --- [ Thread-305] o.s.b.a.mongo.embedded.EmbeddedMongo : 2020-06-24T09:22:53.047+0200 I CONTROL [initandlisten] MongoDB starting : pid=51029 port=63665 dbpath=/var/folders/7x/ss8w17pd4bsfrg1x1t56sl00zq753h/T/embedmongo-db-20d4fbe0-abac-4715-8ae0-b863f7bc9627 64-bit host=M84452
This is discussed in https://github.com/spring-projects/sts4/issues/493.
The short version is that the behavior of the launch configs slightly changed due to the (now correct) usage of the "exclude test classes" checkbox of the Eclipse platform. Make sure that when you re-use existing launch configs that this checkbox is set correctly.
i try to install Oracle Forms and Reports 12.2.1.4, but everytime I run setup.fmw.12.2.1.4.0_fr_win64.exe file Oracle Universal Installer window shows up for a moment with communicate "Preparing the installer...". After that it dissappears and shows again with another communicate: "Cleaning up...". After this communicate, the installer window turns off and there are no other steps.
Screens below
first communicate
second communicate
Did anybody have this problem also? My JAVA_HOME is set as C:\Java\jdk1.8.0_241 and PATH=%JAVA_HOME%\bin.
Here's also -debug log below
m_szTempDirectory: C:\Windows\Temp
Extract to C:\Windows\Temp\sfxCD9A.tmp
Extracting sfx.ini from D:\setup_fmw_12.2.1.4.0_fr_win64.exe to C:\Windows\Temp\sfxCD9A.tmp
Wiz_SingleEntryUnzip (extractAutorun) return code: 0
Total uncompressed size: 2447428290
m_szTempDirectory: C:\Windows\Temp
Extract to same C:\Windows\Temp\sfxCD9A.tmp
Extracting installer files
Wiz_SingleEntryUnzip() result: 0
Total disks: 1 (1)
Finished extracting Disk1
Using version 1.8.0.211.12 of component Disk1\stage\Components\oracle.jre
Jar list: Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar
New command: oracle.jre\.\jdk\jre\bin\java.exe -jar install/modules/ora-launcher.jar
Unzipping Java jars Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar to oracle.jre
Getting size of Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar
Size of Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar: 201205655
Checking space for Java components in C:\Windows\Temp
Unzipping Java jars: Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar
Unzipping Disk1\stage\Components\oracle.jre\1.8.0.211.12\DataFiles\filegroup1.jar
Launch command length: 278
Launch command: "C:\Windows\Temp\sfxCD9A.tmp\oracle.jre\jdk\jre\bin\java.exe" "-Djava.io.tmpdir=C:\Windows\Temp" "-Dsfx.installer.launcher.home=D:\" "-Dsfx.extract.path=C:\Windows\Temp\sfxCD9A.tmp" "-Dsfx.exe=D:\setup_fmw_12.2.1.4.0_fr_win64.exe" -jar install/modules/ora-launcher.jar "-debug"
cmdLine: "C:\Windows\Temp\sfxCD9A.tmp\oracle.jre\jdk\jre\bin\java.exe" "-Djava.io.tmpdir=C:\Windows\Temp" "-Dsfx.installer.launcher.home=D:\" "-Dsfx.extract.path=C:\Windows\Temp\sfxCD9A.tmp" "-Dsfx.exe=D:\setup_fmw_12.2.1.4.0_fr_win64.exe" -jar install/modules/ora-launcher.jar "-debug"
Command successfully started; waiting for completion
Usage: java [-options] class [args...]
(to execute a class)
or java [-options] -jar jarfile [args...]
(to execute a jar file)
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
-server to select the "server" VM
The default VM is server.
-cp <class search path of directories and zip/jar files>
-classpath <class search path of directories and zip/jar files>
A ; separated list of directories, JAR archives,
and ZIP archives to search for class files.
-D<name>=<value>
set a system property
-verbose:[class|gc|jni]
enable verbose output
-version print product version and exit
-version:<value>
Warning: this feature is deprecated and will be removed
in a future release.
require the specified version to run
-showversion print product version and continue
-jre-restrict-search | -no-jre-restrict-search
Warning: this feature is deprecated and will be removed
in a future release.
include/exclude user private JREs in the version search
-? -help print this help message
-X print help on non-standard options
-ea[:<packagename>...|:<classname>]
-enableassertions[:<packagename>...|:<classname>]
enable assertions with specified granularity
-da[:<packagename>...|:<classname>]
-disableassertions[:<packagename>...|:<classname>]
disable assertions with specified granularity
-esa | -enablesystemassertions
enable system assertions
-dsa | -disablesystemassertions
disable system assertions
-agentlib:<libname>[=<options>]
load native agent library <libname>, e.g. -agentlib:hprof
see also, -agentlib:jdwp=help and -agentlib:hprof=help
-agentpath:<pathname>[=<options>]
load native agent library by full pathname
-javaagent:<jarpath>[=<options>]
load Java programming language agent, see java.lang.instrument
-splash:<imagepath>
show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.
dwExitCode: 1
myspawn() result: 1
Press any key to exit
To be clear, you need to start the installer using an elevated shell. This is not the same as being a member of the Windows "Administrator" group. Right-click on the exe and click on "Run as administrator".
Instead of running setup.exe, try execute \install\oui.exe -debug
I have a bunch of unit tests which contain code like:
File file = new File("src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
This test is suddenly failing when running it with Maven Surefire and -DforkCount=0. With -DforkCount=1, it works.
Things I tried so far:
The file does exist. Windows Explorer, command line (copy & paste), text editors, Cygwin can all find it and show the contents. That's why I think it's not a permission problem.
It's not modified by the unit tests or anything else. Git shows no modifications for the last two months.
I've checked the file system, it's clean.
I've tried other versions of Java 8, namely 8u171 and 8u181. Same problem.
I've run Maven from within Cygwin and the command prompt. Same result.
Reboot :-) No effect :-(
More details:
When I see this problem, I start to see the "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" in other projects. That's why I tried forkCount=0 which often helps in this case to find out why the forked VM crashed.
This has started recently, maybe around the October 2018 update of Windows 10. Before that, the builds were rock solid for about three years. My machine was switched to Windows 10 late 2017, I think.
I'm using Maven 3.6 and can't easily try an older version because of an important bug that was fixed with it. I did see the VM crash above with Maven 3.5.2 as well.
It's always the same files which fail (so it's stable).
ulimit (from Cygwin) says:
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 2032
cpu time (seconds, -t) unlimited
max user processes (-u) 256
virtual memory (kbytes, -v) unlimited
I'm wondering if the "open files" limit of 256 only applied to Cygwin processes or whether that's something which Cygwin reads from Windows.
Let me know if you need anything else. I'm running out of ideas what I could try.
Update 1
Bernhard asked me to print absolute names. My answer was that I was already using absolute names but I was wrong. The actual code was:
File file = new File("src/main/java/com/pany/Foo.java");
if (!file.exists()) {
log.debug("Missing file {}", file.getAbsolutePath());
... fail ...
}
... do something with file...
I have now changed this to:
File file = new File("src/main/java/com/pany/Foo.java").getAbsoluteFile();
if (!file.exists()) {
log.debug("Missing file {}", file);
}
and that fixed the problem. I just can't understand why.
When Maven creates a forked VM to run the tests with Surefire, then it can change the current directory. So in this case, it would make sense that the tests work when forked but fail when running in the same VM (since the VM was created in the root folder of the multi-module build). But why is making the path absolute before the call to exists() fixing the issue?
Some background. Each process has a notion of "current directory". When started from the command line, then it's the directory in which the command was executed. When started from the UI, it's usually the folder in which the program (the .exe file) is.
In the command prompt or BASH, you can change this folder with cd for the process which runs the command prompt.
When Maven builds a multi-module project, it has to change this for each module (so that the relative path src/main/java/ always points to the right place). Unfortunately, Java doesn't have a "set current directory" method anywhere. You can only specify one when creating a new process and you can modify the system property user.dir.
That's why new File("a").exists() and new File("a").getAbsoluteFile().exists() work differently.
The latter will use new File(System.getProperty("user.dir"), "a") to determine the path and the former will use the Windows API function _wgetdcwd (docs) which in turn uses a field of the Windows process to get the current directory - in our case, that's always the folder in which Maven was originally started because Java doesn't update the field in the process when someone changes user.dir and Maven can only change this property to "simulate" changing folders.
WinNTFileSystem_md.c calls fileToNTPath(). That's defined in io_util_md.c and calls pathToNTPath(). For relative paths, it will call currentDirLength() which calls currentDir() which calls _wgetdcwd().
See also:
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/WinNTFileSystem_md.c
https://github.com/openjdk-mirror/jdk7u-jdk/blob/jdk7u6-b08/src/windows/native/java/io/io_util_md.c
and here is the place where the Surefire plugin modifies the Property user.dir: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1060
When not forking, it's copied into the current VM's System properties: https://github.com/apache/maven-surefire/blob/56d41b4c903b6c134c5e1a2891f9f08be7e5039f/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1133
So I have checked via printing out the system properties with some simple tests.
During the tests via maven-surefire-plugin the user.dir will be changed to the root of the appropriate module in a multi module build.
But as I mentioned already there is a system property available basedir which can be used to correctly handle the location for tests which needs to access them via File...The basedir is pointed to the location of the pom.xml of the appropriate module.
But unfortunately the basedir property is not set by IDEA IntelliJ during the test run.
But this can be solved by a setup like this:
private String basedir;
#Before
public void before() {
this.basedir = System.getProperty("basedir", System.getProperty("user.dir", "Need to think about the default value"));
}
#Test
public void testX() {
File file = new File(this.basedir, "src/main/java/com/pany/Foo.java");
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
}
This will work in Maven Surefire with -DforkCount=0 as well as -DforkCount=1 and in IDE's (checked only IDEA IntelliJ).
And yes that is an issue in Maven Surefire plugin changing the user.dir.
We might convince IDE's to support the basedir property as well ?
Aaron, we develop the Surefire. We can help you if you provide the path for this:
assertTrue("Missing file: " + file.getAbsolutePath(), file.exists());
Pls post the actual path, expected path and basedir where your POM resides.
The theory would not help here. We are testing all the spectrum of JDKs 7-12 but we do not have the combination Cygwin+Windows which must be considered.
The code setting user.dir in Surefire you mentioned exists a decade.
I am trying my hands on the Stanford dependency parser. I tried running the parser from command line on windows to extract the dependencies using this command:
java -mx100m -cp "stanford-parser.jar" edu.stanford.nlp.trees.EnglishGrammaticalStructure -sentFile english-onesent.txt -collapsedTree -CCprocessed -parserFile englishPCFG.ser.gz
I am getting the following error:
Error occurred during initialization of VM
Too small initial heap
I changed the memory size to -mx1024, -mx2048 as well as -mx4096. It didn't change anything and the error persists.
What am I missing?
Type -Xmx1024m instead of -mx1024.
See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
It should be -mx1024m. I skipped m.
One more thing: in the -cp, the model jar should also be included.
... -cp "stanford-parser.jar;stanford-parser-3.5.2-models.jar"...
(assuming you are using the latest version).
Otherwise an IO Exception will be thrown.
There may be some arguments that are preexisting in the IDE.
In eclipse:
Go to-> Run as-> run configuration-> Arguments
then Delete the arguments that are used previously.
Restart your eclipse.
Worked for me!
I am deploying a large Java project on Sonar using "Findbugs" as profile and getting the error below:
Caused by: java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
Java heap space
What i have tried to resolve this:
Replaced %SONAR_RUNNER_OPTS% with -Xms256m -Xmx1024m to increase the heap size in sonar-runner bat file.
Put "sonar.findbugs.effort" parameter as "Min" in Sonar global parameters.
But both of above methods didn't work for me.
I had the same problem and found a very different solution, perhaps because I'm having a hard time swallowing the previous answers / comments. With 10 million lines of code (that's more code than is in an F16 fighter jet), if you have a 100 characters per line (a crazy size), you could load the whole code base into 1GB of memory. I set it 8GB of memory and it still failed. Why?
Answer: Because the community Sonar C++ scanner seems to have a bug where it picks up ANY file with the letter 'c' in its extension. That includes .doc, .docx, .ipch, etc. Hence, the reason it's running out of memory is because it's trying to read some file that it thinks is 300mb of pure code but really it should be ignored.
Solution: Find the extensions used by all of the files in your project (see more here):
dir /s /b | perl -ne 'print $1 if m/\.([^^.\\\\]+)$/' | sort -u | grep c
Then add these other extensions as exclusions in your sonar.properties file:
sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch
Then set your memory limits back to regular amounts.
%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
this has worked for me:
SONAR_RUNNER_OPTS="-Xmx3062m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m"
I set it direct in the sonar-runner(.bat) file
I had the same problem when running sonar with maven. In my case it helped to call sonar separately:
mvn clean install && mvn sonar:sonar
instead of
mvn clean install sonar:sonar
http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven
Remark: Because my solution is connected to maven, this is not the direct answer for the question. But it might help other users who stumple upon it.
What you can do it to create your own quality profile with just some Findbugs rules at first, and then progressively add more and more until you reach his OutOfMemoryError. There's probably only a single rule that makes all this fail because your code violates it - and if you deactivate this rule, it will certainly work.
I know this thread is a bit old but this info might help someone.
For me the problem was not like suggested by the top-answer with the C++ plugin.
Instead my problem was the Xml-Plugin (https://docs.sonarqube.org/display/PLUG/SonarXML)
after I deactivated it the analysis worked again.
You can solve this issue by increase the maximum memory allocated to the appropriate process by increasing the -Xmx memory setting for the corresponding Java process in your sonar.properties file
under SonarQube/conf/sonar.properties
uncomment below lines and increase the memory as you want:
For Web: Xmx5123m -Xms1536m -XX:+HeapDumpOnOutOfMemoryError
For ElasticSearch: Xms512m -Xmx1536m -XX:+HeapDumpOnOutOfMemoryError
For Compute Engine: sonar.ce.javaOpts=-Xmx1536m -Xms128m -XX:+HeapDumpOnOutOfMemoryError
The problem is on FindBugs side. I suppose you're analyzing a large project that probably has many violations. Take a look at two threads in Sonar's mailing list having the same issue. There are some ideas you can try for yourself.
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td4898141.html
http://sonar.15.n6.nabble.com/java-lang-OutOfMemoryError-Java-heap-space-td5001587.html
I know this is old, but I am just posting my answer anyway. I realized I was using the 32bit JDK (version 8) and after uninstalling it and then installing 64bit JDK (version 12) the problem disappeared.