-
Bug
-
Resolution: Fixed
-
P4
-
21, 23, 24
-
b05
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8337556 | 23.0.2 | Matthias Baesken | P4 | Resolved | Fixed | b01 |
JDK-8338031 | 21.0.5 | Matthias Baesken | P4 | Resolved | Fixed | b03 |
/open_jdk/jdk_test/jdk/src/hotspot/share/code/vtableStubs.hpp:176:60: runtime error: load of value 204, which is not a valid value for type 'bool'
#0 0x110a6ad7e in VtableStubs::entry_point(unsigned char*) vtableStubs.cpp:280
#1 0x10f4cc8e6 in CompiledIC::is_megamorphic() const compiledIC.cpp:293
#2 0x10f4cc95d in CompiledIC::update(CallInfo*, Klass*) compiledIC.cpp:268
#3 0x110592eed in SharedRuntime::resolve_helper(bool, bool, JavaThread*) sharedRuntime.cpp:1366
#4 0x11058c0b3 in SharedRuntime::resolve_virtual_call_C(JavaThread*) sharedRuntime.cpp:1514
#5 0x12cd2e55a (<unknown module>)
#6 0x12580e03b (<unknown module>)
#7 0x12cc1f321 (<unknown module>)
#8 0x12cc1f321 (<unknown module>)
From the comments of the issue it seems while the coding could be improved, the problem is not very severe ("The reason bad bool values are seen is because there is no `VtableStub` object at that location. The reason this works is that we use the data at this location to generate a hash code, do a hash table lookup and then check the actual address for equality. Generating a bogus hash is harmless, ...")
so as long as nothing better was found, we can exclude the method from ubsan checking.
- backported by
-
JDK-8337556 ubsan: vtableStubs.hpp is_vtable_stub exclude from ubsan checks
- Resolved
-
JDK-8338031 ubsan: vtableStubs.hpp is_vtable_stub exclude from ubsan checks
- Resolved
- relates to
-
JDK-8331725 ubsan: pc may not always be the entry point for a VtableStub
- Resolved
- links to
-
Commit openjdk/jdk/486aa11e
-
Commit(master) openjdk/jdk21u-dev/d5782215
-
Commit(master) openjdk/jdk23u/a523870d
-
Review openjdk/jdk/19925
-
Review(master) openjdk/jdk21u-dev/899
-
Review(master) openjdk/jdk23u/41