Bug 247387 – REGRESSION(macOS Ventura): OpenAudible, Eclipse and other Java applications crash when using WebKit

• Component: JavaScriptCore
• Status: RESOLVED FIXED

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!

[Alexey Proskuryakov]

> 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.

[Radar WebKit Bug Importer]

<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.

[Mark Lam]

(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..

[Yijia Huang]

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.

[Lakshmi P Shanmugam]

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).

[Yijia Huang]

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.

[Lakshmi P Shanmugam]

(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!

[Lakshmi P Shanmugam]

(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?

[Yijia Huang]

(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.

[Pierre_T]

Hello @Yijia, 
Do you have any news about the issue?

[Lakshmi P Shanmugam]

(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.

[Paul Gardner]

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..

[Yusuke Suzuki]

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.

[Yusuke Suzuki]

* 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

[Yusuke Suzuki]

OK, found a bug.

[Yusuke Suzuki]

Pull request: https://github.com/WebKit/WebKit/pull/7725

[Yusuke Suzuki]

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.

[Yusuke Suzuki]

Hi! [e-mail]

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

[Yusuke Suzuki]

I reproduced this on macOS Monterey, so removing Ventura from the title.

[Yusuke Suzuki]

Ah, probably Ventura related change.

[Yusuke Suzuki]

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.

[EWS]

Committed 257973@main (0b2785823edb): <https://commits.webkit.org/257973@main>

Reviewed commits have been landed. Closing PR #7725 and removing active labels.

[Lakshmi P Shanmugam]

(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?

[Yusuke Suzuki]

(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 :)

[Paul Gardner]

Not "very easy" when you have 1000s of users out there with an existing JavaApplicationStub gradually upgrading to Ventura!

[Lakshmi P Shanmugam]

(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.

[Lakshmi P Shanmugam]

(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.

[Pierre_T]

Hello,

Do you have any news about the availability of this fix ?

[Ajay Lamba]

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

[Alexey Proskuryakov]

Can you test with the latest macOS beta (13.2, build 22D49)?

[Ajay Lamba]

Ok, will try to install the Beta build but it will take some time.

[Ajay Lamba]

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.