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