Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow instrumenting internal classes #98

Merged
merged 4 commits into from May 12, 2021
Merged

Allow instrumenting internal classes #98

merged 4 commits into from May 12, 2021

Conversation

fmeum
Copy link
Contributor

@fmeum fmeum commented May 11, 2021

Previously these would silently remain uninstrumented as they come with
a null ClassLoader that does not pass the null check.

@fmeum
Allow instrumenting internal classes
31e1581 
Previously these would silently remain uninstrumented as they come with
a null ClassLoader that does not pass the null check.
@fmeum fmeum requested a review from simonresch May 11, 2021 10:11
@fmeum
Copy link
Contributor Author

fmeum commented May 11, 2021 •
edited

@simonresch Instrumenting internal classes outside the default module (e.g., java.desktop) is tricky as of Java 9: As the agent runs in a context that is not module-aware, it can't export CoverageMap to other modules. This leads to NoClassDefFound exceptions when classes from other modules are instrumented.

In order to work around this, we may have to split the runtime package off and turn it into a proper Java 9 module.

The friendly devs of the jigsaw-dev mailing list have helped me resolve this problem.

@fmeum fmeum mentioned this pull request May 11, 2021
Closed
fmeum added 3 commits May 12, 2021 09:24
@fmeum
Make all instrumented modules read the unnamed module
9986d99 
Make all other modules read our (unnamed) module, which allows them to
access the classes needed by the instrumentations, e.g. CoverageMap. If
a module can't be modified, it should not be instrumented as the
injected bytecode might throw NoClassDefFoundError.

https://mail.openjdk.java.net/pipermail/jigsaw-dev/2021-May/014663.html
@fmeum
Load Java no throw methods eagerly
f3972e7 
They will be loaded anyway when the first java.* method is called, which
will probably happen for every non-trivial fuzz target.
@fmeum
Add agent JAR to bootstrap class loader search path
6ef5565 
This allows instrumented classes to reliably find the CoverageMap even
if they use a custom class loader or are located in a different module.

If agent classes are loaded by the bootstrap class loader, they now
need to use the system class loader to load resources.
@fmeum fmeum force-pushed the fix-internal-instrumentation branch from 5e3d5ff to 6ef5565 Compare May 12, 2021 07:27
simonresch
simonresch approved these changes May 12, 2021
View reviewed changes
Copy link
Contributor

@simonresch simonresch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks like a great solution to the modules problem. Very excited about this! :)

@fmeum fmeum merged commit 839883c into main May 12, 2021
@fmeum fmeum deleted the fix-internal-instrumentation branch May 12, 2021 10:35
@fmeum fmeum linked an issue May 12, 2021 that may be closed by this pull request
Classes in named Java 9 modules can't be instrumented #99
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@simonresch simonresch simonresch approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Classes in named Java 9 modules can't be instrumented
2 participants
@fmeum @simonresch