Hi David,
On 03/10/2023 04:49, David Holmes wrote:
What about our own tools that lookup symbols for stacktraces and
hs_err files? Will they be able to find the symbol file?
You make an interesting point. I haven't yet looked into the code for
that tooling to see by which means it resolves debug symbols, by I have
run a basic test that suggests it hasn't got any problems finding them
with the proposed change.
Consider the following code used to cause an access violation in order
to trigger an hs_err report:
public final class ForceCoreDump {
public static void main(String[] args) throws Exception {
java.lang.reflect.Field field =
sun.misc.Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
sun.misc.Unsafe unsafe = (sun.misc.Unsafe) field.get(null);
unsafe.putAddress(0, 0);
}
}
When running this code using a jdk built with external native debug and
my patch that changes the naming convention, it still produces the
following native stack, suggesting symbol resolution works fine:
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffe22b248d7,
pid=10752, tid=10748
#
# JRE version: OpenJDK Runtime Environment (22.0) (build
22-internal-adhoc.fthevene.jdk)
# Java VM: OpenJDK 64-Bit Server VM (22-internal-adhoc.fthevene.jdk,
mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1
gc, windows-amd64)
# Problematic frame:
# V [jvm.dll+0x8848d7] Unsafe_PutLong+0xc7
#
"Unsafe_PutLong+0xc7" in the trace above indicates debug symbols were
resolved: without them, only the lib name and offset would show.
Is there a reason we couldn't rename the dll's so that they do infact
have a prefix e..g libjava.dll? I would presume the linker information
would store the actual name.
Changing the names of the libraries would of course be an alternative
way to accomplish the same result, but I strongly suspect it could have
far more unexpected side-effects than changing the names for the
symbols. In particular, I'm thinking of applications that might
explicitly looking for the presence of a file named "java.dll" to
determine if a Java runtime is present.
I suspect this is a lot more common than programs expecting symbols
explicitly named "java.pdb" (though of course I can't rule out the
possibility that there are). Overall, it seems to me a much riskier
approach.
Cheers,
David
--
Frederic Thevenet
Senior Software Engineer - OpenJDK
Red Hat France<https://www.redhat.com>
BAF5 C2D2 0BE0 1715 5EE1 0815 2065 AD47 B326 EB92
