Support of dynamic attach for Windows ARM 64
Hi, when trying to use the dynamic attach mechanism on Windows ARM 64, we observe the following exception:
java.lang.IllegalStateException: Error during attachment using: INSTANCE
at kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:613)
at kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:586)
at kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:538)
at kotlinx.coroutines.debug.internal.ByteBuddyDynamicAttach.attach(Attach.kt:21)
at kotlinx.coroutines.debug.internal.ByteBuddyDynamicAttach.invoke(Attach.kt:17)
at kotlinx.coroutines.debug.internal.ByteBuddyDynamicAttach.invoke(Attach.kt:15)
at kotlinx.coroutines.debug.internal.DebugProbesImpl.install(DebugProbesImpl.kt:85)
at kotlinx.coroutines.debug.DebugProbes.install(DebugProbes.kt:72)
at com.intellij.diagnostic.CoroutineDumperKt.enableCoroutineDump(coroutineDumper.kt:22)
at com.intellij.idea.StartupUtil$startApplication$4.invokeSuspend(StartupUtil.kt:198)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at kotlinx.coroutines.repackaged.net.bytebuddy.agent.Attacher.install(Attacher.java:106)
at kotlinx.coroutines.repackaged.net.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:608)
... 15 more
Caused by: java.lang.UnsatisfiedLinkError: Unable to load library 'attach_hotspot_windows':
The specified module could not be found.
The specified module could not be found.
The specified module could not be found.
Native library (win32-aarch64/attach_hotspot_windows.dll) not found in resource path ...
that seems to be specific to byte buddy, as other attach_hotspot_windows.dll are stored in the BB's resources.
Unfortunately, this was reported to coroutines (https://github.com/Kotlin/kotlinx.coroutines/issues/3473) by a separate team (that ports IntelliJ IDEA to Win arm64), so I'm rather a middle-man here and neither can provide a lot of context, nor can reactively test the fix on arm64.
Feel free to ask for additional details, I'll try to help as much as I can
You are using Byte Buddy's attach emulation. On Windows, this requires a snippet of native code that needs to be compiled for the targeted architecture. I currently compile this for x86 (32 and 64 bit): https://github.com/raphw/byte-buddy/blob/master/byte-buddy-agent/pom.xml#L180
I am using mingw32 cross-compilers for this purpose. All that would be needed would be to add a compilation for ARM64, too. I need to find some time to see if there's a cross compiler here, so this file would also be available for that architecture: https://github.com/raphw/byte-buddy/blob/master/byte-buddy-agent/src/main/c/attach_hotspot_windows.c
If you can report this back to the team in charge, if they can adjust the POM to include a compilation for ARM64 and send a PR, I can include this in the next release.
Thanks!
I've passed it on to the team, they will decide whether they are willing to contribute, but this is not transparent for me
Unfortunately, this was reported to coroutines (https://github.com/Kotlin/kotlinx.coroutines/issues/3473) by a separate team (that ports IntelliJ IDEA to Win arm64), so I'm rather a middle-man here and neither can provide a lot of context, nor can reactively test the fix on arm64.
"separate team" reporting in: now IntelliJ works fine without that lib. Unless it's super necessary for us, I'll spend time on porting/compiling other more critical libraries.
Sure, let me know if I can help!
We're facing this issue in Amper (using kotlinx-coroutines DebugProbes as well). Are there any plans to support this in the near future?
I won't implement it, also as I lack both hardware and software to test, but I am happy to assist.
I'm a bit surprised by the "Closed as completed" status of this issue, by the way. It bit me again recently. Am I right that it is not completed? Is it possible to keep this issue open, then? 🙏🏻
Indeed, this was incorrectly closed in a batch clean up. Sorry for that.