Change the naming convention for debug symbol files on Windows to avoid collisions (e.g. java.exe/java.dll -> java.pdb)

[Frederic Thevenet]

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