wala / WALA

T.J. Watson Libraries for Analysis, with frontends for Java, Android, and JavaScript, and may common static program analyses
http://github.com/wala/WALA
Eclipse Public License 2.0
755 stars 221 forks source link

SourceDirCallGraph.main run error #1083

Open xubowenW opened 2 years ago

xubowenW commented 2 years ago

When I use maven import the package: com.ibm.wala.cast.java.ecj and run the function : SourceDirGraph.main,the exception was thrown : image

Caused by: java.lang.SecurityException: class "org.eclipse.core.runtime.Plugin"'s signer information does not match signer information of other classes in the same package at java.base/java.lang.ClassLoader.checkCerts(ClassLoader.java:1150)

The libraries(such as org.eclipse.core) in External libraries List were import automatically when load the maven project.

image

Can anyone tell me why does this happen?

Does this have anything to do with my local configuration?

msridhar commented 2 years ago

Thanks for the report. I have just added the SourceDirCallGraph example to the WALA-start project; see https://github.com/wala/WALA-start/commit/c267645aa7926bca5c8b98630d0d05d23dcce2bf. I can run it using this command:

./gradlew -PmainClass=com.ibm.wala.examples.drivers.SourceDirCallGraph run --args="-sourceDir /tmp/srcTest -mainClass LFoo"

In my /tmp/srcTest directory I have the following Foo.java file:

class Foo {
    public static void main(String[] args) {  
    }
}

This works for me; I don't get your crash, and in the end I see:

building call graph...
done
took 1931ms
Call graph stats:
  Nodes: 8
  Edges: 8
  Methods: 8
  Bytecode Bytes: 32

You can see the WALA-start build.gradle here.

Can you let me know what is different about your local configuration? Are you using the released version of WALA, or are you building the master branch from source?

xubowenW commented 2 years ago

Thanks a lot! Now I can run the SourceDirCallGraph.java in the WALA_Start project successfully.

But in my maven project, the problem still exist when I run the SourceDirCallGraph.java . I copy all java files in WALA_Start project into my project. And the difference between WALA_Start and my project is that I used pom.xml to build the project. I used the released version of WALA, and the version number is 1.5.7. The pom.xml is shown in the following figures: image image

msridhar commented 2 years ago

Ok, dug in and I could reproduce your issue. The core problem here is that Eclipse libraries in Maven Central specify their own dependencies with wide version ranges, and do not provide guarantees that a set of dependencies that get pulled in together will be consistent. I am not sure of a good fix.

Looking at the pom.xml files for the 1.5.7 release, there are dependencies like these:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.eclipse.platform</groupId>
        <artifactId>org.eclipse.core.resources</artifactId>
        <version>(,3.15)</version>
      </dependency>
      <dependency>
        <groupId>org.eclipse.platform</groupId>
        <artifactId>org.eclipse.equinox.common</artifactId>
        <version>(,3.15)</version>
      </dependency>
      <dependency>
        <groupId>org.eclipse.platform</groupId>
        <artifactId>org.eclipse.core.commands</artifactId>
        <version>(,3.9.800)</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

These were actually included unintentionally. Gradle knows how to read them, and it forces these (transitive) dependencies back to older versions that make SourceDirCallGraph work. I'm guessing that Maven doesn't know how to read these dependency ranges, so it ends up with inconsistent version numbers. In the latest WALA snapshot versions, these dependencies are not present in the pom.xml, and SourceDirCallGraph from WALA-start doesn't work even with Gradle.

Here are the key dependencies and the exact versions that get pulled in:

|    |    +--- org.eclipse.platform:org.eclipse.equinox.common:{strictly (,3.15)} -> 3.14.100 (c)
|    |    +--- org.eclipse.platform:org.eclipse.core.resources:{strictly (,3.15)} -> 3.14.0 (c)
|    |    \--- org.eclipse.platform:org.eclipse.core.commands:{strictly (,3.9.800)} -> 3.9.700 (c)

Based on that, I added the following to my build.gradle dependencies:

    implementation('org.eclipse.platform:org.eclipse.equinox.common') {
        version {
            strictly '3.14.100'
        }
    }
    implementation('org.eclipse.platform:org.eclipse.core.resources') {
        version {
            strictly '3.14.0'
        }
    }
    implementation('org.eclipse.platform:org.eclipse.core.commands') {
        version {
            strictly '3.9.700'
        }
    }

This makes SourceDirCallGraph work from WALA-start when running on Java 11 (Java 1.8 doesn't work).

For Maven, I think if you add the above dependencies to your POM, that should force their versions. Can you try and see if that fixes things (on Java 11 or higher)?

msridhar commented 2 years ago

To be clear, you should just add dependencies like:

    <dependency>
      <groupId>org.eclipse.platform</groupId>
      <artifactId>org.eclipse.equinox.common</artifactId>
      <version>3.14.100</version>
    </dependency>

And I think that should fix it.

xubowenW commented 2 years ago

Thanks for your advice!!!! I added the dependencies in my pom.xml (on the top of the dependencies list) and solved the problem.

hopeshared-lee commented 6 months ago

I'm trying to run SourceDirCallGraph from Eclipse. No matter Java 8 or 11 been used, it will report error. [-sourceDir, C:/work/walawork/srcTest, -mainClass, LFoo] Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE199E bad major version 61.0 of class=org/eclipse/core/runtime/IProgressMonitor, the maximum supported major version is 55.0; offset=6 at java.base/java.lang.ClassLoader.defineClassImpl(Native Method) at java.base/java.lang.ClassLoader.defineClassInternal(ClassLoader.java:467) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:428) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:1110) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:898) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:806) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:764) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:1075) at com.ibm.wala.cast.java.translator.jdt.ecj.ECJSourceLoaderImpl.getTranslator(ECJSourceLoaderImpl.java:62) at com.ibm.wala.cast.java.loader.JavaSourceLoaderImpl.loadAllSources(JavaSourceLoaderImpl.java:599)

I can see wala 1.6.0 was used. How to solve it? Thanks!

msridhar commented 4 months ago

@hopeshared-lee I think we now require Java 17 for Eclipse-related code. Could you try when running on Java 17?