<div dir="ltr">I tested loading another dynamic library on macos, and the issue disappeared, so it has to be <b>libcrypto</b> to trigger the problem</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">刘希晨 <<a href="mailto:benrush0705@gmail.com">benrush0705@gmail.com</a>> 于2023年8月14日周一 20:44写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Let me add two things:<div>1. I am not using a symbol link, the OPENSSL dynamic library was compiled from source, using the newest version 3.1.2</div><div>2. System.load() is the same as SymbolLookup, jmap and jconsole won't work</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>> 于2023年8月14日周一 20:08写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">cc mailing list<br>
<br>
On 14/08/2023 6:51 pm, 刘希晨 wrote:<br>
> Sorry I am not an export in native debugging, it took me several hours <br>
> finding the actual line causing jconsole and jmap not working properly <br>
> on macos, and except for that, the application works perfectly well in <br>
> my computer, that's the reason why I haven't found the case before, so I <br>
> guess it's not a problem about safepoint, because if this single line <br>
> would cause the application not able to reach a safepoint, why would it <br>
> work on windows, and the application could GC well (I tested add <br>
> System.gc() in the above main method, and it could be done well, I think <br>
> that should suggest the safepoint could be reached, perhaps I am wrong, <br>
> I don't know much about safepoint but it seems GC needs to reach a <br>
> safepoint to run), it runs completely normally except can't be accessed <br>
> by jmap and jconsole (By the way, the application could be debugged by <br>
> idea properly, which is quite suprising, I am using Idea version <br>
> 2023.2), so I guess the openjdk21-ea implementation on macos of <br>
> SymbolLookup should have some problems internally.<br>
<br>
When we are dealing with native code different platforms have different <br>
native code and so they can behave differently. The symptoms you <br>
describe suggest an inability of the VM to reach a safepoint.<br>
<br>
But without getting a native stack dump from a debugger there is no way <br>
to investigate this further.<br>
<br>
Also please respond to the mailing list rather than directly to myself, <br>
so others can see what is happening.<br>
<br>
David<br>
<br>
> David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a> <mailto:<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>>> <br>
> 于2023年8月14日周一 12:51写道：<br>
> <br>
>     On 14/08/2023 2:45 pm, David Holmes wrote:<br>
>      ><br>
>      ><br>
>      > On 14/08/2023 12:42 pm, 刘希晨 wrote:<br>
>      >><br>
>      >> I have found a really strange problem when using project-panama on<br>
>      >> macos, and it might be a bug.<br>
>      >><br>
>      >> *Environment*: JDK-21 ea build 34, cpu : M1 Pro, operating system :<br>
>      >> Ventura 13.5<br>
>      >><br>
>      >> Here are the minimal reproducible codes:<br>
>      >><br>
>      >> public class SimpleExample {<br>
>      >>      public static void main(String[] args)throws Throwable {<br>
>      >>          SymbolLookup crypto =<br>
>      >><br>
>     SymbolLookup.libraryLookup("/Users/liuxichen/workspace/tenet-lib/lib/libcrypto.dylib", Arena.global());<br>
>      >>          Thread.sleep(Long.MAX_VALUE);<br>
>      >>      }<br>
>      >> }<br>
>      >><br>
>      >> The libcrypto.dylib file is the OPENSSL dynamic library file, I<br>
>     think<br>
>      >> other libraries probably could cause the same problem.<br>
>      >><br>
>      >> *Problem description*:<br>
>      >> A normal java program would work fine with *jconsole* and<br>
>     *jmap*, if<br>
>      >> running the above code in macos, jconsole won't be able to<br>
>     connect to<br>
>      >> the target process, and jmap will give the following error:<br>
>      >><br>
>      >> *~/Dow/jdk-21/C/H/bin  jps*<br>
>      >><br>
>      >> 1665 RemoteMavenServer36<br>
>      >> 2673 Jps<br>
>      >> 532<br>
>      >> 1671 Launcher<br>
>      >> 1672 SimpleExample<br>
>      >> 1211<br>
>      >><br>
>      >><br>
>      >> * ~/Dow/jdk-21/C/H/bin  ./jmap -histo:live,file=histo5.data 1672*<br>
>      >><br>
>      >> Exception in thread"main"<br>
>      >> com.sun.tools.attach.AttachNotSupportedException: Unable to open<br>
>      >> socket file<br>
>      >> /var/folders/k4/j5wzcbnd3m96s5lmqw_8lh8r0000gn/T/.java_pid1672:<br>
>     target<br>
>      >> process1672 doesn't respond within 10500ms or HotSpot VM not loaded<br>
>      >> at<br>
>      >><br>
>     jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:95)<br>
>      >>      at<br>
>      >><br>
>     jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)<br>
>      >>      at<br>
>      >><br>
>     jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)<br>
>      >>      at<br>
>     jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:127)<br>
>      >>      at jdk.jcmd/sun.tools.jmap.JMap.histo(JMap.java:199)<br>
>      >>      at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:112)<br>
>      ><br>
>      > These problems, and the workaround, suggest that a thread is<br>
>     preventing<br>
>      > the VM from going to safepoint, but I can't see why that should<br>
>     be the<br>
>      > case. If you apply the StartAttachListener workaround what does<br>
>     jstack<br>
>      > show you is happening?<br>
> <br>
>     Actually if the VM can't reach a safepoint then jstack won't be able to<br>
>     run either. You need to run a native debugger against the process and<br>
>     get the stack traces.<br>
> <br>
>     David<br>
>     ------<br>
> <br>
>      > David<br>
>      > -----<br>
>      ><br>
>      >><br>
>      >> Several tests:<br>
>      >> 1. The above code runs fine on windows and macos, and the process<br>
>      >> could be accessed by jconsole and jmap on windows, only fail on<br>
>     macos<br>
>      >> 2. The problem could be solved by adding VM options, for jconsole<br>
>      >> usable, add -Dcom.sun.management.jmxremote for jmap usable add<br>
>      >> -XX:+StartAttachListener , if there is no<br>
>      >> *SymbolLookup.libraryLookup*(), then jconsole and jmap would<br>
>     work well<br>
>      >> without these two arguments<br>
>      >><br>
>      >> So, I guess there must be some internal logic that blocks the<br>
>     jconsole<br>
>      >> and jmap from entering java program inside<br>
>      >> *SymbolLookup.libraryLookup*(), please correct me if I am wrong<br>
>      >><br>
>      >><br>
>      >><br>
> <br>
</blockquote></div>
</blockquote></div>