Stackoverflow error when upgrading to v3.5.2 #2011
Comments
|
I just discovered that the error happens when I launch all my unit tests in the Maven module, but it's fine if I run the test or the test class only. $ cd myproject/my-mvn-module-1
$ mvn test
#
# [ERROR] MyBeanTest.test1 » StackOverflow
#
$ mvn -Dtest=MyBeanTest test
#
# Tests run: 7, Failures: 0, Errors: 0, Skipped: 0
#
$ mvn -Dtest=MyBeanTest#test1 test
#
# Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
#Maven configuration (in the root pom.xml) : <plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<skipTests>${skip.unit.tests}</skipTests>
<includes>
<include>**/*Test.java</include>
</includes>
<argLine>-Dnet.bytebuddy.experimental=true @{argLine} -Dfile.encoding=${project.reporting.outputEncoding}</argLine>
<trimStackTrace>false</trimStackTrace>
</configuration>
</plugin> |
jdussouillez
changed the title
|
Thanks for reporting. Can you supply an example test case? It looks like an exception is supposed to be thrown but the constructor mocking intercepts its creation where something causes another exception which is again passed to the handler. Do you mock exceptions somewhere? Also, could you share the bottom of the stack trace which is where the circularity is introduced. |
|
Seeing the same thing myself, although I don't have a stable reproduction scenario. The same was observed with |
|
Could you try the latest release to see if the problem still occurs? |
|
Sorry I was not clear originally, I saw the problem at first on |
|
Yes I mock some exceptions in other test classes but the ones who ends with StackoverflowError. I will take some time today or next week to try to reproduce the bug in a small project. The full stacktrace : |
|
This can't be the full stack trace since it needs to origin somewhere. Maybe it's cut off in the print? I think I know the problem and tried to fix it. Unfortunately, we have some release issues but you could build release/3.x locally and try if the problem still occurs. |
|
I'm seeing the same error when trying to go from 3.4.6 to 3.5.0. seems to be related to using a @SPY in the test class, when I change the @SPY to an @mock the error goes away. What seems odd in my case is everything is ok until there are more than 15 tests in the class. 15 tests will pass and any additional tests will fail. The message of the first exception is |
|
@raphw Same issue with v3.5.5. Stacktrace : |
|
@jdussouillez That gets us one step closer but I needed to add an exception for when the error is thrown. Could you build the constructor-dispatch branch locally and see what exception you get in your setup? |
|
That's strange since the exception indicates a scenario that should not occur. I merely fixed the recursion. Can you set a breakppint to see why this happens? What instance is created during spy construction? |
|
@raphw I didn't succeed in setting breakpoints but I added some logs (before this line). Patch : diff --git a/src/main/java/org/mockito/internal/creation/bytebuddy/InlineByteBuddyMockMaker.java b/src/main/java/org/mockito/internal/creation/bytebuddy/InlineByteBuddyMockMaker.java
index 96477f477..6b37ea09e 100644
--- a/src/main/java/org/mockito/internal/creation/bytebuddy/InlineByteBuddyMockMaker.java
+++ b/src/main/java/org/mockito/internal/creation/bytebuddy/InlineByteBuddyMockMaker.java
@@ -265,6 +265,9 @@ public class InlineByteBuddyMockMaker
} else if (type.isInstance(spy)) {
return spy;
} else {
+ System.out.println("type = " + type.getName());
+ System.out.println("object = " + object);
+ System.out.println("spy = " + spy.getClass().getName());
isSuspended.set(true);
try {
// Unexpected construction of non-spied objectLogs (type is always |
|
Could you also add a stack trace at the same spot? ( |
|
Code snippet to dump : try {
Thread.dumpStack();
} catch (Throwable t) {
System.out.println("error while dumping stack: " + t.getMessage());
}
|
|
I thought it would be related to class loading. I am curious however how you end uo with the reflection member accessor. It should be the instrumentation based one. Are you using the latest build? |
I pulled the constructor-dispatch branch this morning before giving you the |
|
Strange, I'll investigate. Could you make sure that you don't have a stale version? You are using mockito-inline or are you configuring the mock maker manually? |
I already checked using
I'm using mockito-core : <dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>3.5.7</version>
<scope>test</scope>
</dependency>And I do not configure anything manually. I just have the |
|
That explains it. You can drop the config and just use the inline artifact which defines the nock maker for you. The member accessor is another plugin which requires manual activation using a similar file if you don't use the other artifact. |
I used mockito-inline v3.5.6, all tests passed but 3. The 3 that fails are new ones (not the ones who failed before) and none of them use Mockito (but all of them are on enums, apparently Do you know how can I generate the inline JAR from the sources ? I can't provide you the logs I added in the source with mockito-inline because the JAR is not generated by |
|
@raphw Thank you for the fix and the time spent on this. It works great ! |
This was referenced Aug 26, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried to upgrade from Mockito v3.4.6 to v3.5.2 and I'm getting a stackoverflow error (same error with v3.5.0) when running some tests (not all of them, just a few ; even in the same class : some tests pass and others don't).
Stacktrace :
I didn't succeed in reproduce the error in a small project, but I'll spend more time to try and post the sources here when/if I have a reproducible case.
Environment :
The text was updated successfully, but these errors were encountered: