Note: this issue is only when dealing with core files.

On SA Attach for linux, a LoadObject is created for each DSO. The LoadObject contains the name, base address, and size of the DSO, and is used to determine if a symbol is located in a DSO.

add_lib_info_fd() is called for each DSO, and later all added "libs" get a LoadObject created for them. add_lib_info_fd() is also called separately for the exec file by the following code:

  if (add_lib_info_fd(ph, exec_file, ph->core->exec_fd,
                      (uintptr_t)0 + find_base_address(ph->core->exec_fd, &exec_ehdr)) == NULL) {
    goto err;
  }

However, this is resulting in a LoadObject with a base address of 0. I think perhaps find_base_address() is not working as expected. For DSOs, the call looks like:

               lib_base = lib_base_diff + find_base_address(lib_fd, &elf_ehdr);
               add_lib_info_fd(ph, lib_name, lib_fd, lib_base);

This works fine for DSOs, and they all have a proper base address. Note for processes the libraries are discovered by scanning /proc/<pid>/maps, and this does properly find the exec file.

As a result of this bug, when LinuxCDebugger.loadObjectContainingPC() is called, which is used mainly by the clhsdb "findpc" command, it will always fail with an NPE:

java.lang.NullPointerException: Cannot invoke "sun.jvm.hotspot.debugger.Address.addOffsetTo(long)" because "base" is null
at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxCDebugger.loadObjectContainingPC(LinuxCDebugger.java:73)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:89)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$7.doit(CommandProcessor.java:616)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2076)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2046)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1926)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:280)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483)

This is because the base address is 0, and in SA if you try to create an Address object for 0, it actually results in null. That is intentional, but for code that is not expecting a null address, you end up with an NPE:

      if (pc.greaterThanOrEqual(base) && pc.lessThan(base.addOffsetTo(size))) {

The bug here is not that the code isn't special casing null to mean 0. Even if it did that it would still fail to lookup any symbols in the exec file. Besides it shouldn't have to check for null since base should never be 0. The bug is that base is 0/null in the first place.

This bug is holding up progress for JDK-8247514 since the updated ClhsdbFindPC tests is now triggering this NPE. Since the proper fix is unclear (I don't have the ELF file knowledge), I'm going to create a subtask with a simple solution to work around the problem.