On 18/12/2020 11:59, Stephan Bergmann wrote:
* The Azul JDK13 works, but after starting an in-process JVM in LO it
crashes with a SIGBUS at
Process 86470 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGBUS
frame #0: 0x000000016bdf41d8
-> 0x16bdf41d8: mov x9, #0x0
0x16bdf41dc: movk x9, #0x0, lsl #16
0x16bdf41e0: mov x10, #0x0
0x16bdf41e4: movk x10, #0x0, lsl #16
Target 0: (soffice) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGBUS
* frame #0: 0x000000016bdf41d8
frame #1: 0x0000000284fb7500
libjavaloaderlo.dylib`com::sun::star::uno::BaseReference::iquery_throw(pInterface=0x0000000287ea59d8,
rType=0x0000000287ea20a0) at Reference.hxx:76:29
frame #2: 0x0000000284fb8ba4
libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::iquery_throw(pInterface=0x0000000287ea59d8)
at Reference.hxx:88:12
frame #3: 0x0000000284fb8b60
libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::Reference(this=0x000000016fdfa6c0,
rRef=0x0000000282591550, (null)=UNO_QUERY_THROW) at Reference.hxx:191:19
frame #4: 0x0000000284fb7108
libjavaloaderlo.dylib`com::sun::star::uno::Reference<com::sun::star::lang::XInitialization>::Reference(this=0x000000016fdfa6c0,
rRef=0x0000000282591550, (null)=UNO_QUERY_THROW) at Reference.hxx:190:1
frame #5: 0x0000000284fb5ffc
libjavaloaderlo.dylib`stoc_javaloader::(anonymous
namespace)::JavaComponentLoader::getJavaLoader(this=0x0000000282591510) at
javaloader.cxx:248:46
frame #6: 0x0000000284fb09a0
libjavaloaderlo.dylib`stoc_javaloader::(anonymous
namespace)::JavaComponentLoader::activate(this=0x0000000282591510,
rImplName=0x00000001157129e8, blabla=0x000000016fdfad78,
rLibName=0x000000016fdfae08, xKey=0x000000016fdfad70) at
javaloader.cxx:317:65
frame #7: 0x000000010124a5d8
libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::loadImplementation(this=0x000000011572a170,
context=0x000000011572a210,
implementation=std::__1::shared_ptr<cppuhelper::ServiceManager::Data::Implementation>::element_type
@ 0x00000001157129e8 strong=3 weak=1) at servicemanager.cxx:849:22
frame #8: 0x000000010124e0cc
libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::findServiceImplementation(this=0x000000011572a170,
context=0x000000011572a210, specifier=0x000000016fdfbc58) at
servicemanager.cxx:1793:9
frame #9: 0x000000010124daa0
libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::createInstanceWithContext(this=0x000000011572a170,
aServiceSpecifier=0x000000016fdfbc58, Context=0x000000011572a210) at
servicemanager.cxx:1000:9
frame #10: 0x000000010124d5b4
libuno_cppuhelpergcc3.dylib.3`cppuhelper::ServiceManager::createInstance(this=0x000000011572a170,
aServiceSpecifier=0x000000016fdfbc58) at servicemanager.cxx:966:12
frame #11: 0x00000001021b5ca0
libfwklo.dylib`framework::DispatchProvider::implts_searchProtocolHandler(this=0x00000001777655e0,
aURL=0x000000016fdfc6d0) at dispatchprovider.cxx:447:25
frame #12: 0x00000001021b4ca4
libfwklo.dylib`framework::DispatchProvider::implts_queryFrameDispatch(this=0x00000001777655e0,
xFrame=0x000000016fdfc180, aURL=0x000000016fdfc6d0,
sTargetFrameName=0x0000000287d5c3b8, nSearchFlags=0) at
dispatchprovider.cxx:355:27
frame #13: 0x00000001021b39fc
libfwklo.dylib`framework::DispatchProvider::queryDispatch(this=0x00000001777655e0,
aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8,
nSearchFlags=0) at dispatchprovider.cxx:103:23
frame #14: 0x00000001021b9cb4
libfwklo.dylib`framework::InterceptionHelper::queryDispatch(this=0x0000000177768fc0,
aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8,
nSearchFlags=0) at interceptionhelper.cxx:81:33
frame #15: 0x000000010234e888 libfwklo.dylib`(anonymous
namespace)::XFrameImpl::queryDispatch(this=0x0000000177765340,
aURL=0x000000016fdfc6d0, sTargetFrameName=0x0000000287d5c3b8,
nSearchFlags=0) at frame.cxx:2338:22
[...]
That's apparently our JIT'ed vtable trampoline code (cf.
generateCodeSnippet in
bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx), and the SIGBUS
smells like a write-vs.-execute issue with pthread_jit_write_protect_np
(<https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon>),
as issued both by us (cf. JitMemoryProtectionGuard in
bridges/source/cpp_uno/shared/vtablefactory.cxx) and by the JVM (as seen
with an lldb breakpoint). Before instantiating the JVM, our
pthread_jit_write_protect_np calls appear to work as intended, and such
JIT'ed vtable trampoline code gets executed. Maybe there's some issue
in the JVM of not pairing calls properly, but I haven't found out
anything for now.
At least with the recent
<https://cdn.azul.com/zulu/bin/zulu17.0.63-ea-jdk17.0.0-ea.27-macosx_aarch64.zip>
on macOS 11.4, things finally appear to reliably work for me (see
<https://git.libreoffice.org/core/+/e529461bcb126e0975ffa3f86e1fd5a630551de2%5E%21>
"Enable JVM also on macOS ARM64")
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
