RFR: 8294689: The SA transported_core.html file needs quite a bit of work [v2]

[Poonam Bajaj]

On Mon, 3 Oct 2022 18:44:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The main issues I set out to address are:
>> 
>> - legacy Solaris references can be removed
>> - add help with dealing with Windows core files, most of important of which is use of PATH to find the dlls referenced by the core file.
>> - add help with dealing with macOS core files, most of important of which is using JAVA_HOME or DYLD_LIBRARY_PATH to find the dlls referenced by the core file. 
>> 
>> However, in the end it turned out to be a pretty substantial restructuring and rewrite.
>> 
>> Here are links to the rendered new and old copies of the file:
>> [new file](https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/6778a202a855a534754c4b47a6cd99cb912869d3/src/jdk.hotspot.agent/doc/transported_core.html)
>> [old file](https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/doc/transported_core.html)
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   some additional clarification on linux and macos

src/jdk.hotspot.agent/doc/transported_core.html line 14:

> 12: produced ("transported core dump"), debuggers (dbx, gdb, windbg or SA) do not
> 13: always successfully open the dump. This is due to kernel, library (shared
> 14: objects or DLLs) mismatch between core dump machine and debugger machine.

Looks like an additional space between _to_ and _library_.

src/jdk.hotspot.agent/doc/transported_core.html line 40:

> 38: Their pages are instead  read from the executable and shared objects (or DLLs).
> 39: Therefore it is important to have a matching java executable and shared object
> 40: files on the debugger machine. The best  way to guarantee this match is to match the

An extra space between _best_ and _way_.

src/jdk.hotspot.agent/doc/transported_core.html line 73:

> 71:  If the debugger machine and core dump machine have identical Windows libraries, then you only
> 72:  need to point SA to the location of the JDK bin directory. This is done by making sure
> 73:  the bin directory is included in the <b>PATH</b> environment variable. If the windows

The location of jvm.dll (e.g. %Java_Home%\bin\server) should be included in the PATH environment variable. And if I remember correctly, the location of 'windbg' should also be added to PATH - this needs to be tested and confirmed though.

-------------

PR: https://git.openjdk.org/jdk/pull/10518