-
Bug
-
Resolution: Fixed
-
P4
-
9, 10, 11, 17, 20
-
b03
-
generic
-
generic
RelocationHolder::RelocationHolder() {
new(*this) Relocation();
}
This is all very contorted and fragile. I wonder why RelocationHolder doesn't just use placement new to (default) construct the Relocation object. e.g.
new (_relocbuf) Relocation();
The other constructor is
RelocationHolder::RelocationHolder(Relocation* r) {
// wordwise copy from r (ok if it copies garbage after r)
for (int i = 0; i < _relocbuf_size; i++) {
_relocbuf[i] = ((void**)r)[i];
}
}
and that comment is just wrong, since the actual object could have been allocated close to the end of accessible memory, with a read beyond its real end potentially resulting in some kind of memory fault.
- duplicates
-
JDK-8160354 uninitialized value warning and VM crash are occurred with GCC 6
- Closed
- relates to
-
JDK-8160310 HotSpot cannot be built with GCC 6
- Resolved
-
JDK-8187676 Disable uninitialized warnings for two files until proper fix available
- Closed
-
JDK-8298912 Make RelocationHolder::reloc const-correct
- Open
-
JDK-8253311 Cleanup relocInfo constructors
- Resolved
-
JDK-8297830 aarch64: Make Address a discriminated union internally
- Resolved
-
JDK-8298913 Add override qualifiers to Relocation classes
- Resolved
-
JDK-8160354 uninitialized value warning and VM crash are occurred with GCC 6
- Closed
-
JDK-8299022 Linux ppc64le and s390x build issues after JDK-8160404
- Resolved