Find a strange problem about using project-panama on macos
刘希晨
benrush0705 at gmail.com
Mon Aug 14 14:34:11 UTC 2023
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/20230814/6900ab90/attachment-0001.htm>
More information about the panama-dev
mailing list