search

javapathfinder / jpf-core

JPF is an extensible software analysis framework for Java bytecode. jpf-core is the basis for all JPF projects; you always need to install it. It contains the basic VM and model checking infrastructure, and can be used to check for concurrency defects like deadlocks, and unhandled exceptions like NullPointerExceptions and AssertionErrors.
535 stars 339 forks source link

Strengthen test case by adding a classfile that mimics a specific bytecode pattern #411

Closed cyrille-artho closed 1 year ago

cyrille-artho commented 1 year ago

There is a test case from an older commit that defines two classes by emitting bytecode: https://github.com/javapathfinder/jpf-core/commit/f5755041fbbe4ea9bc8fedce8fd65781dbac87aa

This requires the ASM library and is a bit complicated for having two simple test classes: example/MyClass1 and example/MyClass2, each with an empty default constructor (which is even generated by the compiler).

It is simpler to have two additional classes in src/tests instead.

zhangwen0411 commented 1 year ago

Hi @cyrille-artho,

The test in https://github.com/javapathfinder/jpf-core/commit/f5755041fbbe4ea9bc8fedce8fd65781dbac87aa was meant to trigger the bug described in #383, which I believe requires that example/MyClass1 and example/MyClass2 not be "loadable" by the default class loader. Defining these two classes via ClassLoader.defineClass is one way to ensure this (and this was how I ran into this bug in the first place), but I think having these classes as .class files would make them visible to the default class loader.

Do you have any easy way of defining these two classes without making them loadable by the default class loader, and without using defineClass?

cyrille-artho commented 1 year ago

As per our discussion, the dynamic generation of the test classes is needed so a class cannot be already loaded by the default class loader. As far as I can tell, we do not use ASM outside that test class, and we do not use different bytecode libraries. The dependence on ASM (or another bytecode library) is therefore inevitable. Alternatives (such as compiling files and moving them to a path outside the class path after compilation) are not necessarily better. So we close this issue.