Closed davidvoit closed 1 year ago
Hi @davidvoit, thx for creating this issue. I wonder how hibernate-validator
plays into this, really interesting. Could you upload your example project somewhere, so that it's easier to reproduce the error?
Sure, here you go: https://github.com/davidvoit/quarkus-jazzer
Just a heads up: The class io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyViolationExceptionMapper
can not be retransform, I couldn't find out why exactly, though. We will continue to look into this.
face same issue here
[ERROR] Errors:
[ERROR] MyFuzzTest.myFuzzTest » IllegalState Failed to run Agent.install
[INFO]
[ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 10.111 s
[INFO] Finished at: 2023-03-06T07:06:03Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on project withdraw-platform: There are test failures.
[ERROR]
[ERROR] Please refer to /server/withdraw-platform/target/surefire-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on project withdraw-platform: There are test failures.
Please refer to /server/withdraw-platform/target/surefire-reports for the individual test results.
Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:347)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.
Please refer to /server/withdraw-platform/target/surefire-reports for the individual test results.
Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
at org.apache.maven.plugin.surefire.SurefireHelper.throwException (SurefireHelper.java:289)
at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution (SurefireHelper.java:161)
at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary (SurefirePlugin.java:364)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked (AbstractSurefireMojo.java:1041)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute (AbstractSurefireMojo.java:857)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:342)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:260)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:172)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:100)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
Instrumenting io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyViolationExceptionMapper
in a standalone test works successfully. I'm not really familiar with Quarkus but I expect it to add its own instrumentation, e.g. tracing, metrics or error handling, which could cause conflicts and prevent further retransformation.
Ignoring not transformable classes should be sufficient in most situations. WDYT?
Yes the Patch is the correct way for now. I will try top investigate the real reason for the error in the quarkus side next week
Quick search didnt show Instrument calls in the quarkus repo - but the GitHub search sucks.
One guess is maybe the jakarta -> javax magic...
Norbert Schneider @.***> schrieb am Di., 7. März 2023, 11:56:
Instrumenting io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyViolationExceptionMapper in a standalone test works successfully. I'm not really familiar with Quarkus but I expect it to add its own instrumentation, e.g. tracing, metrics or error handling, which could cause conflicts and prevent further retransformation. Ignoring not transformable classes should be sufficient in most situations. WDYT?
— Reply to this email directly, view it on GitHub https://github.com/CodeIntelligenceTesting/jazzer/issues/648#issuecomment-1457962709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADDHSUPV75YW54L3G2FPTW24H53ANCNFSM6AAAAAAVOJUPGY . You are receiving this because you were mentioned.Message ID: @.***>
Good old grep to the rescue. It's seems to be comming from the interactive reload/restart support code (RuntimeUpdatesProcessor)
But this means the hibernate class is only the first affected class and a better solutions needs to be found in the quarkus world. I will look if there is someway to disable this instrumentation for fuzzing runs and if I don't find something I will open a ticket on the quarkus side.
Thanks for looking into this :+1:
So looked with a debugger into this, this has nothing todo with Instrumentation, but with junit testrunner order interceptTestClassConstructor from QuarkusTestExtension is not called before the jazzer code is run. This code loads some classes into the classpath if not the class io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyViolationExceptionMapper (and others) are not found. Did confirm this with a breakpoint and evaluate expression. On a normall @Test unit test this class is foud (like you said) but with @FuzzTest it's not available.
The Instrument code is only run in dev mode not in test mode, so doesn't matter here.
Is it possible to somehow priotiorize the junit extensions, so that jazzer`s FuzzTestExtensions is run as last extension after quarkus one?
The quarkus extension is necessary else all the cdi stuff and co is not working.
We continued to look into this issue but, as you said, it seems that the extensions don't work well together. JUnit doesn't guarantee a fixed order in which extension methods are invoked, and in this case actually both extensions skip further execution of the test method.
As far as I can see, Quarkus also creates its own instance of the test class in a dedicated class loader and invokes the test method on that. Currently I suspect that the easiest way would be to use dedicated lifecycle hooks provided by Quarkus.
Sorry for not replying earlier, but this issue sleept through my emails. You are right, this can't be fixed easier and nees more investigation if needed from the quarkus side
Hi! I saw that you are facing this problem. I have written a small library to solve this problem: https://github.com/Algeps/quarkus-test-nmi
Hi Jazzer-Team,
if I create a minimal (empty) Quarkus project with
@QuarkusTest public class FuzzerTest { @FuzzTest public void fuzz(FuzzedDataProvider data) { System.out.println(data.consumeRemainingAsString()); } }
java.lang.IllegalStateException: Failed to run Agent.install
Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.code_intelligence.jazzer.agent.AgentInstaller.install(AgentInstaller.java:46) ... 72 more Caused by: java.lang.InternalError: class redefinition failed: invalid class at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses0(Native Method) at java.instrument/sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:167) at com.code_intelligence.jazzer.agent.Agent.installInternal(Agent.kt:148) at com.code_intelligence.jazzer.agent.Agent.installInternal$default(Agent.kt:36) at com.code_intelligence.jazzer.agent.Agent.install(Agent.kt:33) ... 77 more