If you run the ClhsdbFindPC test with -Xcheck:jni, you will see warnings like
 the following in the log:

WARNING: JNI local refs: 33, exceeds capacity: 32
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(jdk.hotspot.agent@17-internal/Native Method)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(jdk.hotspot.agent@17-internal/LinuxDebuggerLocal.java:355)
- locked <0x00000000891ed9d8> (a sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal)
at sun.jvm.hotspot.HotSpotAgent.attachDebugger(jdk.hotspot.agent@17-internal/HotSpotAgent.java:645)
at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(jdk.hotspot.agent@17-internal/HotSpotAgent.java:583)
at sun.jvm.hotspot.HotSpotAgent.setupDebugger(jdk.hotspot.agent@17-internal/HotSpotAgent.java:360)
at sun.jvm.hotspot.HotSpotAgent.go(jdk.hotspot.agent@17-internal/HotSpotAgent.java:329)
at sun.jvm.hotspot.HotSpotAgent.attach(jdk.hotspot.agent@17-internal/HotSpotAgent.java:155)
- locked <0x00000000891e5d08> (a sun.jvm.hotspot.HotSpotAgent)
at sun.jvm.hotspot.CLHSDB.attachDebugger(jdk.hotspot.agent@17-internal/CLHSDB.java:202)
at sun.jvm.hotspot.CLHSDB.run(jdk.hotspot.agent@17-internal/CLHSDB.java:63)
at sun.jvm.hotspot.CLHSDB.main(jdk.hotspot.agent@17-internal/CLHSDB.java:40)
at sun.jvm.hotspot.SALauncher.runCLHSDB(jdk.hotspot.agent@17-internal/SALauncher.java:280)
at sun.jvm.hotspot.SALauncher$$Lambda$1/0x0000000801001800.accept(jdk.hotspot.agent@17-internal/Unknown Source)
at sun.jvm.hotspot.SALauncher.main(jdk.hotspot.agent@17-internal/SALauncher.java:483)

The culprit seems to be fillThreadsAndLoadObjects(), which is called by attach0(). It allocates localrefs in a loop that is iterated through once per thread, and there is no releasing of these localrefs at the bottom of the loop, so it's no surprise that the capacity is being exceeded.