Add check for static class objects in Node::mayModifyValue #7294
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit fixes a segmentation fault that occurs during
side effect detection in IL generation for an edge case
a static class object reference is passed in as an argument
to Node::mayModifyValue.
Node::mayModifyValue assumes that if its opcode is a store,
the symbol reference whose value it modifies must be one of:
Because of the way that side effects of nodes are
checked by recursively traversing their children
(see J9ByteCodeIlGenerator::valueMayBeModified)
and the way certain IL is generated,
it is possible that these assumptions are not invariant.
In a concrete case, when a awrtbar is generated for static stores,
one of the awrtbar children will be a loadaddr which loads
a static class object. When this case occurs, node::mayModifyValue
will erroneously use the constant pool index of the static class reference
as a static field reference, eventually resulting in a garbage value
and causing a segmentation fault.
Fixes: eclipse-openj9/openj9#18156