During debugging the test code it hangs on the initialization phase.
The latest message at the log is (before the debugging hangs):
2013-03-15 13:03:09:215 INFO [ : ] [main:o.h.d.Dialect] Using dialect: my.company.package.util.hibernate.HSQLDialect
Please consider the following factors which seems to impact the debugging:
Test runs with #RunWith(SpringJUnit4ClassRunner.class)
Test run on IntelliJ IDEA 12.0.4
When tests run without debugging they works without any problems
What to do to debug the code?
Make sure you did not place a breakpoint on method signature instead of line of regular code. You can recognize such breakpoint also by 4 black dots inside red circle. They slow down debugging dramatically.
Try to remove all breakpoints and restart your Debug.
Press Command+Shift+F8, then Command+A and press Del. This if for Mac.
It could easily be that you need to supply the test with more PermGen space.
Try using this in your configurations for that test:
-XX:MaxPermSize=300m
If your tests aren't insanely huge (and they shouldn't be), this should be more than enough.
Related
Hello, everybody!
I am trying to debug my java8 application running on tomcat 7 with Intellij IDEA Remote Debug.
The problem is when i run debug in idea all off my breakpoints are set to invalid with message:
Line numbers info is not available in class pathToClass
Here is my JAVA_OPTS settings from catalina.bat:
set "JAVA_OPTS=%JAVA_OPTS% -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9999 %JSSE_OPTS%"
Here is my remote debug settins from IDEA
At one point in your build process your Java code is compiled in to classes with the javac compiler (or something equivalent). There is an option to the compiler to include debug information (including line numbers) which you apparently do not have enabled at the moment.
For plain javac add -g.
For ant add debug="true" to the javac task.
For Maven, the default configuration for the maven-compiler-plugin adds debug information, so the explicit setting not to has to be undone.
At one point in your build process your Java code is compiled in to
classes with the javac compiler (or something equivalent). There is an
option to the compiler to include debug information (including line
numbers) which you apparently do not have enabled at the moment. How
do you compile your code? – Thorbjørn Ravn Andersen
Adding debug="true" option to javac solving this problem.
Thanks everybody who helped.
I had the same problem. But the accepted answer did not solve it for me. In my case, the root cause was an interference caused by clover gradle plugin.
To debug the issue, I compared the source code of class A.java with the decompiled code of A.class. The decompiled version had a bunch of junk generated by clover. I just removed the clover plugin from the project, deleted the build folder, invalidated the cache and restarted IDEA. I added the breakpoint and ran it in debug. Voila! It worked this time.
It may not be clover in your case; It could be something else. But, most probably, this breakpoints issue is caused by a mismatch between your source code and compiled class. The best way to verify is to compare the decompiled class with its source.
This can be caused by the minify. Go to your Gradle and set:
Enabled=false
buildShrinkResources=false
Then sync and debug again.
Just had a problem like that, lines were out of sync with a remote server, although the connection was established(I was able to see thread list in IDEA).
The first thing I tried was to put breakpoints not on statements, but on the whole method. Debug hit the breakpoint, but in a weird place(on closing curly brace).
All I had to do, is to remove one empty line from the start of my file, and everything just got aligned with remote.
Environment
I'm currently trying to run JavaFX GUI tests via xvfb on multiple environments on Travis CI. I'm using Gradle to run these tests while using the TestFX and NestedRunner testing frameworks to write them. Before running the tests, export DISPLAY=:99.0 is called.
Context
There are times when the build succeeds and other times when it fails. However, I've noticed that Gradle outputs a single line that I can use to predict when the build will succeed or fail.
Before that line appears, one will see the following in the Travis CI log:
:richtextfx:compileJava
:richtextfx:processResources
:richtextfx:classes
:richtextfx:compileTestJava
:richtextfx:processTestResources
:richtextfx:testClasses
After that, one of two lines appears that predicts whether the build will succeed/fail:
on success: :richtextfx:testXlib: extension "RANDR" missing on display ":99.0".
on failure: :richtextfx:test
My Question
Why does Gradle change the test task to testXlib task? What are the inner mechanisms that handle this? And what does it all mean?
Gradle for sure does not do this. I've never heard of a task called testXlib and also the complete Gradle source does not contain this character sequence.
Either your build script does this, or some plugin you apply, or an init script that is applied by Travis CI.
Try to increase the logging level to debug and also add a call to tasks --all, maybe that will shed some light.
In eclipse, if I run a Java program in debug mode with no breakpoints, and if the JVM hits a NullPointerException, Eclipse will kindly highlight the offending line of code, and show the local variables, etc. Execution is paused. I can evaluate code using the Display tab, and so on.
But, if I run a JUnit test in debug mode, and the jvm hits a NullPointerException, the jvm does not pause, and I don't have a chance to see the local variables.
Is it possible to run JUnit tests so that the JVM will pause automatically when I hit a NullPointerException, without using breakpoints?
Edit:
Using JUnit 4 & Juno
Eclipse stops when the exception that's thrown is uncaught and would bump you out of main(). However, when you run with JUnit framework, all exceptions are caught by JUnit, so Eclipse does not stop.
Two solutions come to mind:
set exception breakpoint to stop when NullPointerException is thrown
use the exception's stack trace reported by JUnit and set the breakpoint on the line that throws the exception (that's the one I prefer).
Open the Junit test case or Junit Test Suite you want to run.
Place your Break Point.
Right Click on the File and click on Debug As > Junit Test.
Double click set breakpoint
Use Debug mode to run in Eclipse
Hover on that line of code, and then click step over or f6
You can see it on JUnit tab, if you double-click on the line that has a problem, you'll go to the location where the null-pointer exception happened.
java.lang.NullPointerException <--First line of the error
at.com.myProject.MyClass.myMethod(MyClass.java:theLineOfMyCode) <-- the line that you should double-click
After you do this, you will be redirected to the line of the error.
Just been playing around for the first time with IntelliJ IDEA Community edition, first time I have worked with it so if I'm missing something, please excuse me.
I have a bunch of unit tests which I run, however, when running them in IntelliJ (with the standard setup out of the box), I intermittently get the following error in the console:
03:14:17 Failed to start: 58 passed, 1 not started
I have searched the web but to no avail. If I run just the test that failed, it may or may not print out a similar error:
03:19:54 Failed to start: 0 passed, 1 not started
If I keep trying, eventually it works and tells me that all of my tests have passed.
The image is not the error as an exclamation mark, it is a different error icon (), which I do not recognise. The error in Event Log window appears as red text.
It always appears to happen with only one test and it is always the same test for any given set of tests. I.E. In a different project, the same issue also appears, but for a different test (but it's always the same one in each project or set of tests).
One more thing to note is that this ONLY happens when debugging and not when running, so it may be something to do with connecting the debugger?
It all works perfectly fine with Eclipse.
Any ideas what could be causing this?
The issue for me is Failed to start: 1, passed: 0 . I'm using Spring Boot 2.4.0 with Junit5 to test the Controller Class. I just commented out the version tag in the junit-jupiter-engine dependency. Then it worked. Really strange. It might helpful for someone.
I got the same error. It was something weird sent to System.out that made IntellJ IDEA test "not started".
I've created a ticket for IntelliJ IDEA, you can vote for it if you still encounter this problem.
In my case problem was in pom.
I moved from fulling working application to spring-boot implementation and only imported spring-boot-starter-test in dependency for testing.
I solved by excluding junit part from spring-boot-starter-test and added junit dependency of latest version in separate block.
Sometimes similar error happens with scala code when you mix sclamock's MockFactory with scalatest's AsyncFlatSpec.
So, be sure to use AsyncMockFactory like below.
class ExampleSpec extends AsyncFlatSpec with AsyncMockFactory
Looks like this may have been a bug on IntelliJ, it has been raised with them.
I had this problem (in Android Studio but its a customised IntelliJ) and the reason was WHERE the cursor was when I ran tests using CTRL-SHIFT-F10.
#Parameterized.Parameters
public static Collection data()
Once I moved the cursor into a test method or not inside any method, it worked.
I had the same issue. Whatever be the number of scenarios, it was showing 1 extra scenario in NOT STARTED stage. I was using Scenario Outline to run tests and had commented the rows in the Example tables.
I later found out that commenting the whole example table (which I didn't wanted to run) resolved the issue rather than commenting each row.
I had the same issue that cracked me up a little in IntelliJ IDEA 2017.2.1. The test case ran without any recognizable errors or irregularities, but in the end JUnit claimed the case as not started.
Figured out it was caused by trying to print into a PrintWriter that has already been closed.
In my case I was trying to mock a class having a public static method. Problem solved when everything is set free from static context.
I came along not started tests, when attempting to test code that called System.exit(1) . IntelliJ would not start my tests until I removed the exiting behavior like this:
At first I replaced all direct lines in the code from
System.exit(1)
to
onFailure.run();
with
unnable onFailure = () -> System.exit(1);
in the code itself. In the Test-Code I replaced the Runnable with a testable mock Runnable
Runnable mockOnFailure =
() -> {
throw new CustomError(
"Some descriptive message here.");
};
and than I expected that Error to be thrown like so (using AssertJ for nice assertion statements)
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatExceptionOfType;
assertThatExceptionOfType(CustomError.class).isThrownBy(
() -> {
callingCodeThatCallsOnFailure();
}
);
Now the tests are all being startet by the IDE as desired.
Feel free to reuse that if it is of help to you. I do not claim any ownership or copyright to any of those lines of code.
I am trying to trouble shoot a JUnit. In the source code, I have set break point in two places: 1) in a line where a static member is initialized 2) the first line of one of the test cases.
The debugger stops in the static field initializing line. But it doesn't stop in the test case. No matter where I set the break point in the test case, the debugger doesn't stop there. I know for sure that the test case is executed as I can see the log messages that I have added appear in the log.
Any help would be greatly appreciated.
I am using Eclipse Galileo and JUnit4 launcher.
Fix could be as simple as clicking run/skip all breakpoints. Worked for me.
Make sure, under Run > Debug Configurations, that 'Stop in main' is selected, if applicable to your situation.
This could be related to one of the bugs in JDK 6 Update 14, as indicated in the release notes for JDK 6 update 15.
If this indeed turns out to be the issue, you should move to a higher version of the JDK (that's no guarantee though, since fixes have been released against 6u16, 6u18 and 7b1). The best bet is to use -XX:+UseParallelGC flag. Increasing the size of the minimum and maximum heap size, to delay the first GC, bring temporary relief.
By the way, use this bug report in Eclipse to track how others have been faring.
You might have accidentally skipped all break points in Eclipse toolbar. To fix this go to Eclipse -> Run -> Skip All Breakpoints.
Usually when this happens to me (rare but it does) means that the code being executed is different than the code in the editor. It will happen from time to time for Eclipse that the built classes and the code in editor are out of sync. When that happens I get all sort of weird debugger behavior (debugging empty lines, skipping lines of code etc).
Restarting Eclipse, clean all projects and rebuild everything usually clears things up. I had also the Maven plugins (older versions... had not had it for a while now) that had a tendency to do that too.
Otherwise it might be a bug, maybe the one Vineet stated,
Hope this helps
In my case the problem was that I hadn't Debug view open in Debug perspective, so:
1 - Be sure you have debug perspective opened:
2 - Be sure you have debug view opened:
Project -> Clean seemed to work for me on on JRE 8
In order to debugger work with remote, the java .class files must be complied along with debugging information. If "-g:none" option was passed to compiler then the class file will not have necessary information and hence debugger will not be able to match breakpoints on source code with that class in remote. Meanwhile, if jars/class files were obfuscated, then they also will not have any debug info. According to your responses, most probably this is not your case, but this info could be useful for others who face the same issue.
Remove all breakpoints and re-add them.
For JDK7, run->Debug Configurations, check "Keep JUnit running after a test run when debugging".
Happened to me once, when I had unchecked "Run > Build automatically" and forgot to re-check it.
Make sure you declare the package at the top.
In my groovy code this stops at breakpoints:
package Pkg1
import java.awt.event.ItemEvent;
isMule = false
class LineItem {
// Structure defining individual DB rows
public String ACCOUNT_CODE
public String ACCOUNT_DESC
...
This does not stop at breakpoints:
import java.awt.event.ItemEvent;
isMule = false
class LineItem {
// Structure defining individual DB rows
public String ACCOUNT_CODE
public String ACCOUNT_DESC
...
To remove the breakpoints:
Debug your class as a junit test
When your debugger stops, click the "breakpoints" tab next to "variables" and "expressions"
At the top right of the breakpoint tab, click the button with two 'X'
Stop the test, replace your breakpoint and run the debugger again
Also verify if breakpoints on other lines DO work, it may be a bug in the debugger. I have had a problem with the Eclipse debugger where putting a breakpoint on a boolean assignment whose code was on the next line didn't work I reported this here, but putting it on the previous or next line did.
If nothing works-
Remove that Remote/Local Debug Configuration, and Create a new One.
Add the Source in Debug Configurations.
Another possible problem is that the debugger port may be blocked by the firewall. For example, I was using mule anypoint studio (v 5.4.3). The default debugger port is 6666. When a flow is executed, it would not stop at breakpoint. when I changed the port to another (e.g. 8099), it worked fine.
Go to Right click->Debug Configuration and check if too many debug instances are created.
My issue was resolved when i deleted multiple debug instances from configuration and freshly started debugging.
If you are on Eclipse,
Right click on your project folder under "Package Explorer".
Goto Source -> Clean up and choose your project.
This will cleanup any mess and your break-point should work now.
Creating a new workspace worked for me.
In my case I had multiple projects in same workspace. The java file I was trying to debug was present in more than one projects with same package.
I didn't need the other project, so simply closed unrelated projects (or remove the file from unrelated project).
One additional comment regarding Vineet Reynolds answer.
I found out that I had to set -XX:+UseParallelGC in eclipse.ini
I setup the virtual machine (vm) arguments as follows
-vmargs
-Dosgi.requiredJavaVersion=1.7
-Xms512m
-Xmx1024m
-XX:+UseParallelGC
-XX:PermSize=256M
-XX:MaxPermSize=512M
that solved the issue.
It happened to me when I had several project, I realized that I created a spring boot configuration of a project B from a project A (I clicked on Duplicate and change the parameter to have a config for the project B) and in that case I haven't the debug mode so I removed this config and I created directly a new one by clicking New in Spring Boot App
This is what works for me:
I had to put my local server address in the PHP Server configuration like this:
Note: that address, is the one I configure in my Apache .conf file.
Note: the only breakpoint that was working was the 'Break at first line', after that, the breakpoints didn't work.
Note: check your xdebug properties in your php.ini file, and remove any you think is not required.