Skip to content

The key name in java.test.config should align with the launch configuraiton #852

Closed

Description

I have the following defined in my workspace /.vscode/settings.json

"java.test.config": {
        "name": "GhidraTest",
        "vmArgs": ["-Djava.system.class.loader=ghidra.GhidraClassLoader", "-Declipse.project.dir=${workspaceFolder}", "-Dpython.console.encoding=UTF-8", "-Dfile.encoding=UTF8", "-Dlog4j.skipJansi=true", "-Duser.country=US", "-Duser.language=en", "-Dsun.stdout.encoding=UTF-8", "-Dsun.err.encoding=UTF-8", "-Dvisualvm.display.name=Ghidra"]
    }

Upon running a test and explicitly selecting the GhidraTest configuration option the following output is produced. Note the incorrect vmargs. (If args is set they also get ignored.)

Launching with the following launch configuration: '{
  "name": "Launch Java Tests",
  "type": "java",
  "request": "launch",
  "mainClass": "org.eclipse.jdt.internal.junit.runner.RemoteTestRunner",
  "projectName": "Ghidra-Cpp-Class-Analyzer",
  "classPaths": [
    "C:\\Users\\astre\\Documents\\Ghidra-Cpp-Class-Analyzer\\bin\\main",
    "C:\\Users\\astre\\Documents\\Ghidra-Cpp-Class-Analyzer\\bin\\test",
    -snipped- # ghidra jars. .classpath works
    "C:\\Users\\astre\\.vscode-insiders\\extensions\\redhat.java-0.52.0\\server\\config_win\\org.eclipse.osgi\\75\\0\\.cp",
    "C:\\Users\\astre\\.vscode-insiders\\extensions\\redhat.java-0.52.0\\server\\config_win\\org.eclipse.osgi\\46\\0\\.cp"
  ],
  "modulePaths": [],
  "args": [
    "-version",
    "3",
    "-port",
    "58930",
    "-testLoaderClass",
    "org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader",
    "-loaderpluginname",
    "org.eclipse.jdt.junit4.runtime",
    "-test",
    "ghidra.app.cmd.data.rtti.gcc.TypeInfoTest:test",
    "-port",
    "58929",
    "-port",
    "58929"
  ],
  "vmArgs": [
    "-ea"
  ],
  "encoding": "utf8",
  "env": {
    -snipped-
  },
  "console": "internalConsole",
  "noDebug": true
}'
%TESTC  1 v2
%TSTTREE1,test(ghidra.app.cmd.data.rtti.gcc.TypeInfoTest),false,1,false,-1,test(ghidra.app.cmd.data.rtti.gcc.TypeInfoTest),,
%TESTS  1,test(ghidra.app.cmd.data.rtti.gcc.TypeInfoTest)
%ERROR  1,test(ghidra.app.cmd.data.rtti.gcc.TypeInfoTest)
%TRACES 
java.lang.NullPointerException
	at ghidra.app.cmd.data.rtti.gcc.TypeInfoTest.test(TypeInfoTest.java:19)
	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:567)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at generic.test.TestThread.run(TestThread.java:106)
%TRACEE 
%TESTE  1,test(ghidra.app.cmd.data.rtti.gcc.TypeInfoTest)
%RUNTIME6062

The NullPointerException that is causing my test to fail is because the extension points aren't being loaded which I think is because the classloader isn't being set.

Activity

  1. jdneo commented on Oct 25, 2019

    @jdneo
    Member

    Hi Andrew Strelsky (@astrelsky),

    I'm not quite sure, but I guess you have also set the setting: java.test.defaultConfig. If that is the case, you can just remove that setting or set it to "GhidraTest".

    Please feel free to let me know if this can resolve your problem

  2. astrelsky commented on Oct 25, 2019

    @astrelsky
    Author

    Hi Andrew Strelsky (@astrelsky),

    I'm not quite sure, but I guess you have also set the setting: java.test.defaultConfig. If that is the case, you can just remove that setting or set it to "GhidraTest".

    Please feel free to let me know if this can resolve your problem

    I initially had it set to that but removed it and explicitly selected "GhidraTest" as a sanity check. The same results are produced.

  3. jdneo commented on Oct 25, 2019

    @jdneo
    Member

    Hmm, I was trying to repro this issue but not able to.

    The implementation is here: https://github.com/microsoft/vscode-java-test/blob/master/src/utils/launchUtils.ts#L58-L60

    The vmargs should be inserted. (Suppose you are using JUnit 4)

  4. astrelsky commented on Oct 25, 2019

    @astrelsky
    Author

    Hmm, I was trying to repro this issue but not able to.

    The implementation is here: https://github.com/microsoft/vscode-java-test/blob/master/src/utils/launchUtils.ts#L58-L60

    The vmargs should be inserted. (Suppose you are using JUnit 4)
    I'm attaching the full unedited (except for a few privacy snips) output of the java language server and java test runner to this comment.

    If I must I'll attempt to debug the test runner tomorrow. No matter what configuration I make or set I get the same results.

    language_server.log
    test_runner.log

    These are both my global and workspace settings.
    workspace:

    {
        "java.autobuild.enabled": true,
        "java.test.config": {
            "name": "GhidraTest",
            "workingDirectory": "${workspaceFolder}",
            "args": ["-c", "ghidra.GhidraClassLoader"],
            "vmArgs": ["-Djava.system.class.loader=ghidra.GhidraClassLoader", "-Declipse.project.dir=${workspaceFolder}", "-Dpython.console.encoding=UTF-8", "-Dfile.encoding=UTF8", "-Dlog4j.skipJansi=true", "-Duser.country=US", "-Duser.language=en", "-Dsun.stdout.encoding=UTF-8", "-Dsun.err.encoding=UTF-8", "-Dvisualvm.display.name=Ghidra"]
        },
        "java.dependency.packagePresentation": "flat"
    }
    

    global:

    {
        "telemetry.enableTelemetry": false,
        "java.format.settings.url": "${env:GHIDRA_SRC}\\eclipse\\GhidraEclipseFormatter.xml",
        "java.format.settings.profile": "GhidraEclipseFormatter",
        "editor.suggestSelection": "first",
        "vsintellicode.modify.editor.suggestSelection": "automaticallyOverrodeDefaultValue",
        "java.configuration.checkProjectSettingsExclusions": false,
        "java.trace.server": "verbose",
        "terminal.integrated.rendererType": "dom",
        "workbench.startupEditor": "newUntitledFile",
        "java.codeGeneration.useBlocks": true,
        "java.completion.guessMethodArguments": true,
        "java.completion.importOrder": [
            "java",
            "ghidra",
            "javax",
            "com",
            "org"
        ],
        "java.implementationsCodeLens.enabled": true,
        "java.referencesCodeLens.enabled": true,
        "java.errors.incompleteClasspath.severity": "ignore",
        "java.test.report.position": "currentView",
        "python.jediEnabled": false,
        "python.insidersChannel": "off",
        "java.test.report.showAfterExecution": "always",
        "java.test.message.hintForSetingDefaultConfig": false,
        "explorer.confirmDelete": false,
        "java.test.log.level": "verbose",
        "files.associations": {
            "*.jj": "java"
        },
        "editor.tokenColorCustomizations": {
            "[sleigh]": {
                "comments": "#229977"  
            }
        },
        "java.codeGeneration.generateComments": true,
        "java.completion.overwrite": false,
        "java.maven.downloadSources": true,
        "java.debug.logLevel": "verbose"
    }
    
  5. jdneo commented on Oct 25, 2019

    @jdneo
    Member

    Hi Andrew Strelsky (@astrelsky),

    I guess I found the root cause. It should be vmargs, not vmArgs.

    I need to find out a way to validate the key names in the implementation. Or make it align with the launch configuration. Sorry for the confusion.

  6. changed the title [-]TestRunner ignoring "java.test.config" setting[/-] [+]The key name in `java.test.config` should align with the launch configuraiton[/+] on Oct 25, 2019
  7. astrelsky commented on Oct 25, 2019

    @astrelsky
    Author

    Hi Andrew Strelsky (@astrelsky),

    I guess I found the root cause. It should be vmargs, not vmArgs.

    I need to find out a way to validate the key names in the implementation. Or make it align with the launch configuration. Sorry for the confusion.

    Yes this was the cause. The good old copypasta strikes again. Thank you for your help. I'll leave this open until the naming situation is resolved.

  8. added
    engDebts for engineering
    and removed on Oct 15, 2020
  9. added this to the 0.25.0 milestone on Oct 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    engDebts for engineering

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions