-
Enhancement
-
Resolution: Fixed
-
P4
-
11, 15, 16
-
b09
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8251901 | 15.0.2 | Aleksey Shipilev | P4 | Resolved | Fixed | b01 |
JDK-8251960 | 15.0.1 | Aleksey Shipilev | P4 | Resolved | Fixed | b06 |
JDK-8257957 | 13.0.6 | Yuri Nesterenko | P4 | Resolved | Fixed | b03 |
JDK-8252421 | 11.0.9 | Aleksey Shipilev | P4 | Resolved | Fixed | b06 |
I was debugging some new VM patch, and figured it was a memory stomp due to wrong index passed to objArrayOopDesc::obj_at_put. That method does not assert the index at all, which hides the errors and silently corrupts the heap, until something else discovers it. Some objArrayOopDesc accessors do verify the index against the bounds.
Same thing goes for typeArrayOopDesc.
Same thing goes for typeArrayOopDesc.
- backported by
-
JDK-8251901 Make sure {type,obj}ArrayOopDesc accessors check the bounds
- Resolved
-
JDK-8251960 Make sure {type,obj}ArrayOopDesc accessors check the bounds
- Resolved
-
JDK-8252421 Make sure {type,obj}ArrayOopDesc accessors check the bounds
- Resolved
-
JDK-8257957 Make sure {type,obj}ArrayOopDesc accessors check the bounds
- Resolved
- relates to
-
JDK-8189871 Refactor GC barriers to use declarative semantics
- Resolved
-
JDK-8197999 Accessors in typeArrayOopDesc should use new Access API
- Resolved
(1 relates to, 2 links to)