RelocationHolder has a _relocbuf member, which is really just storage for a Relocation object. The constructors for RelocationHolder are both problematic. The no-arg constructor is
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.
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-8253311 Cleanup relocInfo constructors
-
- Resolved
-
-
JDK-8160354 uninitialized value warning and VM crash are occurred with GCC 6
-
- Closed
-