Created attachment 463372 [details] VM Crash Log Java GUI applications that use webkit are now failing for users that have upgraded to Ventura running on Intel. (M1/Rosetta users not affected.) This will break a lot of apps that embed a browser into a java based desktop app, as google.com's main page can't be rendered without crashing. Two github issues are tracking this (with full crash logs and a discussion): https://github.com/openaudible/openaudible/issues/1050 https://github.com/eclipse-platform/eclipse.platform.swt/issues/452 This is an odd problem, as running from command line (using "java -jar application.jar) does not crash, but running using the Eclipse launcher, or the very common Instal4J "JavaApplicationStub" launcher will crash. One can reproduce this by downloading OpenAudible for Intel on Intel machine running Mac OS 13 (Ventura) and select menu "Controls: Connect to Audible" Eclipse is also having this issue, but not positive full steps to open the eclipse web browser. Would be nice to be able to run this against a debug version of JavaScriptCore and drop into a debugger to see what is going on.. Our apps have worked up until the first reports on Ventura beta. I'm seeing SIGSEGV, SIGNAL, Code 5 Trace/BPT and SIGABRT errors, all about 4 recursion levels into llint_entry. Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0x000045a3f1a440a4 C [JavaScriptCore+0x55177c] llint_entry+0x1d192 C [JavaScriptCore+0x552615] llint_entry+0x1e02b C [JavaScriptCore+0x55177c] llint_entry+0x1d192 C [JavaScriptCore+0x55177c] llint_entry+0x1d192 C [JavaScriptCore+0x5343e7] vmEntryToJavaScript+0xd8 C [JavaScriptCore+0xccf61d] JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)+0x45d C [JavaScriptCore+0xf7957a] JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)+0xfa Attached is a typical crash log. Any assistance appreciated!
> One can reproduce this by downloading OpenAudible for Intel on Intel machine running Mac OS 13 (Ventura) and select menu "Controls: Connect to Audible" I can reproduce as described. Got different looking crashes a couple rimes, but they didn't seem any more helpful. Hitting the same kind of crash under lldb, so it doesn't look like JVM signal handler mangles the report too much.
<rdar://problem/101892715>
If it helps I can build a small Mac intel app that just launches a browser that can be used for testing. Maybe quit with a result 0 if the page loads correctly.
(In reply to openaudible from comment #3) > If it helps I can build a small Mac intel app that just launches a browser > that can be used for testing. Maybe quit with a result 0 if the page loads > correctly. Yes, please. That would be immensely helpful.
I posted code and binary to reproduce this bug. https://github.com/openaudible/swt_browser_test and https://github.com/openaudible/swt_browser_test/releases/latest There is an unsigned .dmg with an unsigned .app. Instructions for running from terminal are included.... but essentially open the dmg and run: /Volumes/SWTBrowserTest/SWTBrowserTest.app/Contents/MacOS/JavaApplicationStub Which should quickly bring up the Mac crash dialog. Source code and installer files are all included. Hopefully you can figure it out..
Thanks. That would be really helpful.
Hi Jijia, I just updated the test executable so it is signed. https://github.com/openaudible/swt_browser_test/releases Should work on M1 Ventura and fail on Intel Ventura. Let me know if you have any questions and keep us posted. I'm seeing a few other developers impacted by this.
Hi team, can you please provide any updates for this issue or suggest possible workarounds in the application code? It currently seems to affect all Eclipse/SWT based products using the Webkit browser and running on macOS Ventura (Intel).
Hi developers, Sorry for late rely. In recent weeks, all the team members are tight in various deadlines and schedules. The crash is due to the `BAD_ADDRESS_ACCESS` of one register with null value. I am currently working on this one and trying to figure out why is null. Hopefully, we can fix this one by the end of this week.
(In reply to Yijia Huang from comment #9) > Hi developers, > > Sorry for late rely. In recent weeks, all the team members are tight in > various deadlines and schedules. The crash is due to the > `BAD_ADDRESS_ACCESS` of one register with null value. I am currently working > on this one and trying to figure out why is null. Hopefully, we can fix this > one by the end of this week. Thanks Yijia for the quick response, looking forward to the fix!
(In reply to Yijia Huang from comment #9) > Hi developers, > > Sorry for late rely. In recent weeks, all the team members are tight in > various deadlines and schedules. The crash is due to the > `BAD_ADDRESS_ACCESS` of one register with null value. I am currently working > on this one and trying to figure out why is null. Hopefully, we can fix this > one by the end of this week. @Yijia, any updates on the issue?
(In reply to Lakshmi P Shanmugam from comment #11) > (In reply to Yijia Huang from comment #9) > > Hi developers, > > > > Sorry for late rely. In recent weeks, all the team members are tight in > > various deadlines and schedules. The crash is due to the > > `BAD_ADDRESS_ACCESS` of one register with null value. I am currently working > > on this one and trying to figure out why is null. Hopefully, we can fix this > > one by the end of this week. > > @Yijia, any updates on the issue? Hi @Lakshmi, we are still working on this. It seems to be more complicated than we thought, and we need more time to figure it out.
Hello @Yijia, Do you have any news about the issue?
(In reply to Yijia Huang from comment #12) > (In reply to Lakshmi P Shanmugam from comment #11) > > (In reply to Yijia Huang from comment #9) > > > Hi developers, > > > > > > Sorry for late rely. In recent weeks, all the team members are tight in > > > various deadlines and schedules. The crash is due to the > > > `BAD_ADDRESS_ACCESS` of one register with null value. I am currently working > > > on this one and trying to figure out why is null. Hopefully, we can fix this > > > one by the end of this week. > > > > @Yijia, any updates on the issue? > > Hi @Lakshmi, we are still working on this. It seems to be more complicated > than we thought, and we need more time to figure it out. Hi @Yijia, more and more Eclipse users are affected by this as they upgrade to macOS 13. It basically makes Eclipse unusable on macOS 13 on Intel Macs. Can you please suggest any interim workarounds that can be used in the client code until it's fixed in Webkit? I believe disabling javascript avoids the crash, but JS support is required in many applications and can't be used as a workaround.
Not just Eclipse, the BiglyBT application also becomes unusable...
Maybe we can help debug. I'm a little rusty... so bare with me. Where is the source code that crashes? Line number? Is the code open source? If there is a null register dereference, what does that register contain when it isn't null and working (say, on an M1 or earlier build)? (For instance, is it a string, object pointer, etc? Can a dummy variable be used (empty string, for instance.)) Where is the Webkit object code on the Mac? Which file contains the crash? Is it possible to build from source and replace the existing code? Can the code be built with debug symbols and breakpoints be set? Can debugging code be added to the code in question? (if (x==null) log.error. If you set a debugger break BAD_ADDRESS_ACCESS, is there a stacktrace that helps explain what that register is? Is there source code for the object code that crashes? Line of code where it crashes? Really would be best to update the source to allow a breakpoint where the trouble is and stop the program before it happens, while simultaneously doing the same breakpoints on a working version. If it were me, I'd start with some of the above..
So far, Justin and Yijia found that this crash does not happen when Oracle's JDK is used. We are wondering whether this issue would be related to OpenJDK, but anyway, using the latest Oracle's JDK is a workaround.
* thread #1: tid = 0xdff9c3, 0x00004283f7c14104, queue = 'com.apple.main-thread, stop reason = EXC_BAD_ACCESS (code=1, address=0x58) frame #0: 0x00004283f7c14104 #BRfkoG [Baseline bc#35](Cell[Object]: 0x8818eee0, \"prv:a-sc-define\", Cell[Function]: 0x88885340) frame #1: 0x0000000053279c50 #Ab6r6D [LLInt bc#2581](Cell[JSWindowProxy]: 0x5c115ae8, Cell[Object]: 0x8818e200, Cell[JSWindowProxy]: 0x5c115ae8) frame #2: 0x000000005327acc6 #EfqiQt [LLInt bc#161](Cell[JSWindowProxy]: 0x5c115ae8, Cell[Object]: 0x8818e200, Cell[JSWindowProxy]: 0x5c115ae8) frame #3: 0x0000000053279c50 #Bfg4Vo [LLInt bc#200](Undefined, Cell[Function]: 0x8886e0a0) frame #4: 0x0000000053279c50 <global>#AyZ5Su [LLInt bc#75](Cell[JSWindowProxy]: 0x5c115ae8) frame #5: 0x000000005325548d JavaScriptCore`vmEntryToJavaScript + 286 frame #6: 0x0000000053e778eb JavaScriptCore`JSC::JITCode::execute(this=0x000000005c18cf00, vm=0x0000000088419000, protoCallFrame=0x00007ff7b9024408) at JITCodeInlines.h:42:38 frame #7: 0x00000000542d3222 JavaScriptCore`JSC::Interpreter::executeProgram(this=0x0000000088425940, source=0x00007ff7b90250c0, (null)=0x0000000088140068, thisObj=0x000000005c115ae8) at Interpreter.cpp:1011:31 frame #8: 0x0000000054719c29 JavaScriptCore`JSC::evaluate(globalObject=0x0000000088140068, source=0x00007ff7b90250c0, thisValue=JSValue @ 0x00007ff7b9024aa0, returnedException=0x00007ff7b9024d00) at Completion.cpp:137:37 frame #9: 0x0000000054719d7a JavaScriptCore`JSC::profiledEvaluate(globalObject=0x0000000088140068, reason=Other, source=0x00007ff7b90250c0, thisValue=JSValue @ 0x00007ff7b9024b10, returnedException=0x00007ff7b9024d00) at Completion.cpp:152:12 frame #10: 0x00000000954e554a WebCore`WebCore::JSExecState::profiledEvaluate(lexicalGlobalObject=0x0000000088140068, reason=Other, source=0x00007ff7b90250c0, thisValue=JSValue @ 0x00007ff7b9024c00, returnedException=0x00007ff7b9024d00) at JSExecState.h:104:27 frame #11: 0x00000000954e4fbd WebCore`WebCore::ScriptController::evaluateInWorld(this=0x000000005c014600, sourceCode=0x00007ff7b90250b8, world=0x000000005c0d1760) at ScriptController.cpp:156:27 frame #12: 0x00000000954e4d59 WebCore`WebCore::ScriptController::evaluateInWorldIgnoringException(this=0x000000005c014600, sourceCode=0x00007ff7b90250b8, world=0x000000005c0d1760) at ScriptController.cpp:123:19 frame #13: 0x00000000954e57f5 WebCore`WebCore::ScriptController::evaluateIgnoringException(this=0x000000005c014600, sourceCode=0x00007ff7b90250b8) at ScriptController.cpp:175:12 frame #14: 0x0000000095e44492 WebCore`WebCore::ScriptElement::executeClassicScript(this=0x0000000089015120, sourceCode=0x00007ff7b90250b8) at ScriptElement.cpp:456:21 frame #15: 0x0000000095dbb760 WebCore`WebCore::LoadableClassicScript::execute(this=0x000000005c132920, scriptElement=0x0000000089015120) at LoadableClassicScript.cpp:173:19 frame #16: 0x0000000095e45dd2 WebCore`WebCore::ScriptElement::executeScriptAndDispatchEvent(this=0x0000000089015120, loadableScript=0x000000005c132920) at ScriptElement.cpp:571:24 frame #17: 0x0000000095e460b3 WebCore`WebCore::ScriptElement::executePendingScript(this=0x0000000089015120, pendingScript=0x000000005c4f74e0) at ScriptElement.cpp:588:13 frame #18: 0x0000000095e7dd2e WebCore`WebCore::ScriptRunner::timerFired(this=0x000000005c055d00) at ScriptRunner.cpp:139:27 frame #19: 0x0000000095e8b9f7 WebCore`decltype(__f=0x000000005c128188, __a0=0x000000005c128198)).*fp()) std::__1::__invoke<void (WebCore::ScriptRunner::*&)(), WebCore::ScriptRunner*&, void>(void (WebCore::ScriptRunner::*&)(), WebCore::ScriptRunner*&) at type_traits:3688:1 frame #20: 0x0000000095e8b970 WebCore`std::__1::__bind_return<void (WebCore::ScriptRunner::*)(), std::__1::tuple<WebCore::ScriptRunner*>, std::__1::tuple<>, __is_valid_bind_return<void (WebCore::ScriptRunner::*)(), std::__1::tuple<WebCore::ScriptRunner*>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<void (__f=0x000000005c128188, __bound_args=size=1, (null)=__tuple_indices<0> @ 0x00007ff7b9025468, __args=size=0)(), std::__1::tuple<WebCore::ScriptRunner*>, 0ul, std::__1::tuple<> >(void (WebCore::ScriptRunner::*&)(), std::__1::tuple<WebCore::ScriptRunner*>&, std::__1::__tuple_indices<0ul>, std::__1::tuple<>&&) at functional:2852:12 frame #21: 0x0000000095e8b929 WebCore`std::__1::__bind_return<void (WebCore::ScriptRunner::*)(), std::__1::tuple<WebCore::ScriptRunner*>, std::__1::tuple<>, __is_valid_bind_return<void (WebCore::ScriptRunner::*)(), std::__1::tuple<WebCore::ScriptRunner*>, std::__1::tuple<> >::value>::type std::__1::__bind<void (this=0x000000005c128188)(), WebCore::ScriptRunner*>::operator()<>() at functional:2885:20 frame #22: 0x0000000095e8b8ae WebCore`WTF::Detail::CallableWrapper<std::__1::__bind<void (WebCore::ScriptRunner::*&)(), WebCore::ScriptRunner*>, void>::call(this=0x000000005c128180) at Function.h:53:39 frame #23: 0x0000000092361572 WebCore`WTF::Function<void ()>::operator(this=0x000000005c055d70)() const at Function.h:82:35 frame #24: 0x00000000924d3d5e WebCore`WebCore::Timer::fired(this=0x000000005c055d48) at Timer.h:135:9 frame #25: 0x0000000096d65228 WebCore`WebCore::ThreadTimers::sharedTimerFiredInternal(this=0x000000005c0103f0) at ThreadTimers.cpp:127:23 frame #26: 0x0000000096d6ee11 WebCore`WebCore::ThreadTimers::setSharedTimer(this=0x000000005c0085e8)::$_0::operator()() const at ThreadTimers.cpp:67:80 frame #27: 0x0000000096d6ed9e WebCore`WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::$_0, void>::call(this=0x000000005c0085e0) at Function.h:53:39 frame #28: 0x0000000092361572 WebCore`WTF::Function<void ()>::operator(this=0x000000009ac08958)() const at Function.h:82:35 frame #29: 0x0000000096d10cfb WebCore`WebCore::MainThreadSharedTimer::fired(this=0x000000009ac08950) at MainThreadSharedTimer.cpp:83:5 frame #30: 0x0000000096df3f06 WebCore`WebCore::timerFired((null)=0x00006000001f1440, (null)=0x0000000000000000) at MainThreadSharedTimerCF.cpp:85:40 frame #31: 0x00007ff81f99e1b9 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 frame #32: 0x00007ff81f99dca8 CoreFoundation`__CFRunLoopDoTimer + 923 frame #33: 0x00007ff81f99d818 CoreFoundation`__CFRunLoopDoTimers + 307 frame #34: 0x00007ff81f983f66 CoreFoundation`__CFRunLoopRun + 2010 frame #35: 0x00007ff81f9830cc CoreFoundation`CFRunLoopRunSpecific + 562 frame #36: 0x00007ff8207ded5a Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 216 frame #37: 0x000000000ace0b29 libswt-pi-cocoa-4954r7.jnilib`Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend_1bool__JJJJ + 57 frame #38: 0x000000001a55c217 0x1357c76c frame #39: 0x000000001357c76c 0x128dc267 frame #40: 0x00000000128dc267 frame #41: 0x00000000128dc267 0x128dc267 frame #42: 0x00000000128dc267 frame #43: 0x00000000128dc267 frame #44: 0x00000000128d2cc9 frame #45: 0x0000000009e9e73e libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 510 frame #46: 0x000000000a16e86f libjvm.dylib`invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 1347 frame #47: 0x000000000a16e2e2 libjvm.dylib`Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 244 frame #48: 0x0000000009f288a7 libjvm.dylib`JVM_InvokeMethod + 542 frame #49: 0x00000000128e1a10 frame #50: 0x00000000128dbfc0 0x128dbfc0 frame #51: 0x00000000128dbfc0 frame #52: 0x00000000128dc0a2 frame #53: 0x00000000128dbfc0 frame #54: 0x00000000128dc267 0x128d2cc9 frame #55: 0x00000000128d2cc9 frame #56: 0x0000000009e9e73e libjvm.dylib`JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 510 frame #57: 0x0000000009ee3c45 libjvm.dylib`jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 266 frame #58: 0x0000000009ee752a libjvm.dylib`jni_CallStaticVoidMethod + 466 frame #59: 0x0000000008d3ab1d libjli.dylib`JavaMain + 2736 frame #60: 0x0000000008d3d065 libjli.dylib`__JVMInit_block_invoke + 75 frame #61: 0x00007ff8207c0b31 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 7 frame #62: 0x00007ff8207c0a29 Foundation`-[NSBlockOperation main] + 98 frame #63: 0x00007ff8207c09bf Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 17 frame #64: 0x00007ff8207bfc2b Foundation`-[NSOperation start] + 785 frame #65: 0x00007ff820800817 Foundation`__NSThreadPerformPerform + 179 frame #66: 0x00007ff81f98540b CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 frame #67: 0x00007ff81f985373 CoreFoundation`__CFRunLoopDoSource0 + 180 frame #68: 0x00007ff81f9850ed CoreFoundation`__CFRunLoopDoSources0 + 242 frame #69: 0x00007ff81f983b08 CoreFoundation`__CFRunLoopRun + 892 frame #70: 0x00007ff81f9830cc CoreFoundation`CFRunLoopRunSpecific + 562 frame #71: 0x0000000008d3c64e libjli.dylib`CreateExecutionEnvironment + 398 frame #72: 0x0000000008d3885e libjli.dylib`JLI_Launch + 1322 frame #73: 0x0000000006edc155 JavaApplicationStub`-[Launcher launch] + 2485 frame #74: 0x0000000006edc875 JavaApplicationStub`launcher_main + 645 frame #75: 0x0000000006edc9e2 JavaApplicationStub`main + 34 frame #76: 0x0000000006ed3b54 JavaApplicationStub`start + 52
OK, found a bug.
Pull request: https://github.com/WebKit/WebKit/pull/7725
Ah, yeah, the root cause was found, but looks like this is very specific to this application. Is this application has very special entitlement? It seems that memory mapping pattern is vastly different from the other normal process (e.g. WebContent process), and it is contradicting with the WebKit's assumption.
Hi! openaudible@email.tg It looks like the application binary is specifying DYLD configuration, which specifically reduces the PAGEZERO from 4GB (default) to 64KB. This changes what address mmap returns, and gets invariant of JavaScriptCore broken. (mmap returns address larger than 4GB). You can workaround the issue by changing PAGEZERO DYLD flag to default 4GB. $ otool -l /Volumes/OpenAudible/OpenAudible.app/Contents/MacOS/JavaApplicationStub /Volumes/OpenAudible/OpenAudible.app/Contents/MacOS/JavaApplicationStub: Load command 0 cmd LC_SEGMENT_64 cmdsize 72 segname __PAGEZERO vmaddr 0x0000000000000000 vmsize 0x0000000000010000 fileoff 0 filesize 0 maxprot 0x00000000 initprot 0x00000000 nsects 0 flags 0x0 ... Other app (e.g. iTerm2) /Applications/iTerm.app/Contents/MacOS/iTerm2: Load command 0 cmd LC_SEGMENT_64 cmdsize 72 segname __PAGEZERO vmaddr 0x0000000000000000 vmsize 0x0000000100000000 fileoff 0 filesize 0 maxprot 0x00000000 initprot 0x00000000 nsects 0 flags 0x0
I reproduced this on macOS Monterey, so removing Ventura from the title.
Ah, probably Ventura related change.
Yup, now the following can be explained, > This is an odd problem, as running from command line (using "java -jar application.jar) does not crash, but running using the Eclipse launcher, or the very common Instal4J "JavaApplicationStub" launcher will crash. JavaApplicationStub has DYLD loader command using 64KB for PAGEZERO, but java command does not have that.
Committed 257973@main (0b2785823edb): <https://commits.webkit.org/257973@main> Reviewed commits have been landed. Closing PR #7725 and removing active labels.
(In reply to EWS from comment #26) > Committed 257973@main (0b2785823edb): > <https://commits.webkit.org/257973@main> > > Reviewed commits have been landed. Closing PR #7725 and removing active > labels. Yay! Thanks a lot for fixing this, @Yusuke! When will the fix be available for users? How do we get the fixed Webkit version on macOS 13?
(In reply to Lakshmi P Shanmugam from comment #27) > (In reply to EWS from comment #26) > > Committed 257973@main (0b2785823edb): > > <https://commits.webkit.org/257973@main> > > > > Reviewed commits have been landed. Closing PR #7725 and removing active > > labels. > > Yay! Thanks a lot for fixing this, @Yusuke! > > When will the fix be available for users? How do we get the fixed Webkit > version on macOS 13? Hello! Apple does not mention to the future release plan in general (to avoid confusion). But since there is very easy workaround https://bugs.webkit.org/show_bug.cgi?id=247387#c22, you can just try this workaround and address the issue right now :)
Not "very easy" when you have 1000s of users out there with an existing JavaApplicationStub gradually upgrading to Ventura!
(In reply to Yusuke Suzuki from comment #28) > (In reply to Lakshmi P Shanmugam from comment #27) > > (In reply to EWS from comment #26) > > > Committed 257973@main (0b2785823edb): > > > <https://commits.webkit.org/257973@main> > > > > > > Reviewed commits have been landed. Closing PR #7725 and removing active > > > labels. > > > > Yay! Thanks a lot for fixing this, @Yusuke! > > > > When will the fix be available for users? How do we get the fixed Webkit > > version on macOS 13? > > Hello! > > Apple does not mention to the future release plan in general (to avoid > confusion). > But since there is very easy workaround > https://bugs.webkit.org/show_bug.cgi?id=247387#c22, you can just try this > workaround and address the issue right now :) The workaround suggested was "changing PAGEZERO DYLD flag to default 4GB". Does it refer to the linker flag -pagezero_size <size> or a different flag? The linker flag cannot be seen as workaround because it involves building/linking the application and wouldn't fix the problem for the existing users of the application. It'll be very helpful to the Eclipse and Java community if the Webkit fix can be made available to the users at the earliest as it's a blocker to moving to macOS Ventura.
I talked to EJ Technologies/Install4J who wrote the JavaApplicationStub. "The lower pagezero size is unfortunately required for the OpenJ9 JVM so we cannot generally change that." They have a version of JavaApplicationStub that uses the default page size available by asking support. The changes requires Install4j 10 and the updated JavaApplicationStub can be placed in install4j10/resource/macos. Thanks everyone for the assistance getting this identified.
(In reply to openaudible from comment #31) > > "The lower pagezero size is unfortunately required for the OpenJ9 JVM so we > cannot generally change that." > Same case with Eclipse launcher, lower pagezero size is required to support OpenJ9.
Hello, Do you have any news about the availability of this fix ?
Our application also crashed after 4-5 seconds of starting. Below is the crash report: Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [24935] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x5c2ccbabc6bb ??? 1 ??? 0x0 ??? 2 JavaScriptCore 0x7ff82f2b5e38 llint_entry + 121870 3 JavaScriptCore 0x7ff82f2b62c4 llint_entry + 123034 4 JavaScriptCore 0x7ff82f2b6251 llint_entry + 122919 5 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 6 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 7 JavaScriptCore 0x7ff82f2b62c4 llint_entry + 123034 8 JavaScriptCore 0x7ff82f2b62c4 llint_entry + 123034 9 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 10 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 11 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 12 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 13 JavaScriptCore 0x7ff82f2b554b llint_entry + 119585 14 JavaScriptCore 0x7ff82f2b53b8 llint_entry + 119182 15 JavaScriptCore 0x7ff82f298027 vmEntryToJavaScript + 216 16 JavaScriptCore 0x7ff82fa3316d JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*) + 1117 17 JavaScriptCore 0x7ff82fcde5fa JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) + 250 18 WebCore 0x7ff83375772c WebCore::JSExecState::profiledEvaluate(JSC::JSGlobalObject*, JSC::ProfilingReason, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) + 92 19 WebCore 0x7ff8337573c8 WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld&) + 200 20 WebCore 0x7ff8337577c5 WebCore::ScriptController::evaluateIgnoringException(WebCore::ScriptSource Code const&) + 53 21 WebCore 0x7ff833ad8a8a WebCore::ScriptElement::executeClassicScript(WebCore::ScriptSourceCode const&) + 586 22 WebCore 0x7ff833aa7247 WebCore::LoadableClassicScript::execute(WebCore::ScriptElement&) + 151 23 WebCore 0x7ff833ad90a9 WebCore::ScriptElement::executePendingScript(WebCore::PendingScript&) + 137 24 WebCore 0x7ff833adbf08 WebCore::ScriptRunner::timerFired() + 184 25 WebCore 0x7ff834159f48 WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebC ore::SharedTimer*)::$_0, void>::call() + 152 26 WebCore 0x7ff83264274f WebCore::timerFired(__CFRunLoopTimer*, void*) + 31 27 CoreFoundation 0x7ff8153c9996 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20 28 CoreFoundation 0x7ff8153c94fe __CFRunLoopDoTimer + 820 29 CoreFoundation 0x7ff8153c9114 __CFRunLoopDoTimers + 285 30 CoreFoundation 0x7ff8153afa5c __CFRunLoopRun + 2098 31 CoreFoundation 0x7ff8153aebb0 CFRunLoopRunSpecific + 560 32 Foundation 0x7ff81620749a -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 216 33 libswt-pi-cocoa-4954r7.jnilib 0x2bb60b29 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend_1bool__JJJJ + 57 34 ??? 0x1ac10187 ??? 35 ??? 0x14133c74 ??? 36 ??? 0x12bec203 ??? 37 ??? 0x12bec203 ??? 38 ??? 0x12bec248 ??? 39 ??? 0x12bec248 ??? 40 ??? 0x12bec203 ??? 41 ??? 0x12bec056 ??? 42 ??? 0x12bec203 ??? 43 ??? 0x12bec203 ??? 44 ??? 0x12bec248 ??? 45 ??? 0x12bec203 ??? 46 ??? 0x12bebc40 ??? 47 ??? 0x12bebc40 ??? 48 ??? 0x12bec056 ??? 49 ??? 0x12bec056 ??? 50 ??? 0x12bebf80 ??? 51 ??? 0x12bebf80 ??? 52 ??? 0x12bebf80 ??? 53 ??? 0x12be2cc9 ??? 54 libjvm.dylib 0x9a82f73 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 599 55 libjvm.dylib 0x9d49c4c invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2072 56 libjvm.dylib 0x9d493ea Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 244 57 libjvm.dylib 0x9b0632c JVM_InvokeMethod + 448 58 ??? 0x12bf1930 ??? 59 ??? 0x12bebf80 ??? 60 ??? 0x12bebf80 ??? 61 ??? 0x12bec056 ??? 62 ??? 0x12bebf80 ??? 63 ??? 0x12bec203 ??? 64 ??? 0x12bec203 ??? 65 ??? 0x12be2cc9 ??? 66 libjvm.dylib 0x9a82f73 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 599 67 libjvm.dylib 0x9ac1864 jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 621 68 libjvm.dylib 0x9ac2f05 jni_CallIntMethod + 371 69 eclipse_11700.so 0x13f7fca startJavaJNI + 1946 70 eclipse_11700.so 0x13f3eb0 _run + 6016 71 eclipse_11700.so 0x13f227a run + 426 72 provar 0x12999f7 original_main + 1319 73 provar 0x129a3a7 main + 1655 74 dyld 0x7ff814fa5310 start + 2432
Can you test with the latest macOS beta (13.2, build 22D49)?
Ok, will try to install the Beta build but it will take some time.
Ventura 13.2 is GA now. I tried running my application on Ventura 13.2 and it is working fine. No crash occurred. So the issue is fixed by Apple in Ventura 13.2 release.