eclipse.platform.swt
eclipse.platform.swt copied to clipboard
Crash in Embedded WebKit on macOS 15.4 (ARM64) with Eclipse 4.35.0
System Info:
OS: macOS 15.4 (Sonoma)
Architecture: Apple Silicon (ARM64)
JVM: Eclipse OpenJ9 VM 21.0.6.0 (build openj9-0.49.0, JRE 21 Mac OS X aarch64-64-Bit 20250121_371 (JIT enabled, AOT enabled)
Eclipse: 4.35.0 (Build ID: 4.35.0.20250306-0811)
SWT Library: libswt-pi-cocoa-4968r13.jnilib
System Integrity Protection: Enabled
Crash Summary:
The Eclipse application crashes with a SIGABRT due to EXC_BAD_ACCESS (null pointer dereference) in the main UI thread.
The crash originates in the WebKit engine via the SWT Cocoa integration, specifically in layout management:
WebCore::BackForwardCache::markPagesForContentsSizeChanged
WebCore::LocalFrameView::setContentsSize
...
WebHTMLView layoutToMinimumPageWidth
...
Java_org_eclipse_swt_internal_cocoa_OS_objc_msgSendSuper
Steps to Reproduce:
Launch Eclipse 4.35.0 on macOS 15.4 using an ARM64 JDK.
Interact with the editor window (key, mouse)
Eclipse abruptly terminates with a crash report indicating SIGABRT and JVM abort. (about every 20 min)
Crash Report Snippet:
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
...
libjvm.dylib os::abort()
WebCore markPagesForContentsSizeChanged
WebKitLegacy -[WebHTMLView layoutToMinimumPageWidth:...]
libswt-pi-cocoa-4968r13 Java_org_eclipse_swt_internal_cocoa_OS_objc_msgSendSuper
Same for me also on Eclipse 2024-12 (4.34) and 2024-06 (4.32):
- Eclipse 2024-12 (4.34) or 2024-06 (4.32)
- OpenJDK 64-Bit Server VM Temurin-21.0.6+7
- macOS 15.4 Sequoia (not crashing on Sonoma 14.7.4)
- WebKit 20621.1.15.11.10
- ARM Mac Mini M4
Steps to reproduce for me are:
- Ensure Javadoc View is closed
- In a Java Editor hover over code so that the Javadoc displays in a popup, and ensure to move the mouse into the Javadoc popup so that it gets focus and scrollbars are shown in the popup.
- Open the Javadoc View
- Hover over code again as in (2)
- Crash
Perhaps a regression introduced in macOS 15.4.
Unfortunately this makes Eclipse on Mac unusable when using Webkit in any way.
Switch zu external Browser (General->Webbrowser) and save often. Then you can work with some crashes.
Switch zu external Browser (General->Webbrowser) and save often. Then you can work with some crashes.
This won't help. Webkit is used internally for the Javadoc. Eclipse is crashing for me very minute or so just by working in a Java editor.
Same problem for me.
- Eclipse 2025-03 (4.35)
- OpenJDK 64-Bit Server VM Temurin-21.0.6+7
- macOS 15.4
- ARM Mac M2 Pro
Different way to reproduce
- Ensure Javadoc View is open
- In a Java Editor hover over code so that the Javadoc displays in a popup, and ensure to hover the mouse into the Javadoc popup so that scrollbars are shown in the popup
- Click into the Java Editor so that it tries to update the Javadoc View
- Crash
I think a key thing here is to ensure that the vertical scroll bar appears in the Javadoc hover and the Javadoc View gets updated. The crash log suggests this may have something to do with it:
Stack: [0x000000016ed30000,0x000000016f52c000], sp=0x000000016f527b50, free space=8158k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [WebCore+0x1dbe5e8] WebCore::BackForwardCache::markPagesForContentsSizeChanged(WebCore::Page&)+0xe4
C [WebCore+0x2382364] WebCore::LocalFrameView::setContentsSize(WebCore::IntSize const&)+0x104
C [WebCore+0x238318c] WebCore::LocalFrameView::adjustViewSize()+0x60
C [WebCore+0x23a0b7c] WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x660
C [WebCore+0x2385ff8] WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C [WebKitLegacy+0x106d0] -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C [WebKitLegacy+0xcf0c] -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x88
C [WebCore+0x1249c5c] WebCore::ScrollView::platformSetScrollbarModes()+0x28
C [WebCore+0x178c0] WebCore::ScrollView::setScrollbarModes(WebCore::ScrollbarMode, WebCore::ScrollbarMode, bool, bool)+0xfc
C [WebCore+0x2386fac] WebCore::LocalFrameView::willDoLayout(WTF::WeakPtr<WebCore::RenderElement, WTF::SingleThreadWeakPtrImpl, WTF::RawPtrTraits<WTF::SingleThreadWeakPtrImpl>>)+0x434
C [WebCore+0x23a0920] WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x404
C [WebCore+0x2385ff8] WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C [WebKitLegacy+0x106d0] -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C [WebKitLegacy+0xd32c] -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x4a8
C [WebCore+0x1249c5c] WebCore::ScrollView::platformSetScrollbarModes()+0x28
C [WebCore+0x178c0] WebCore::ScrollView::setScrollbarModes(WebCore::ScrollbarMode, WebCore::ScrollbarMode, bool, bool)+0xfc
C [WebCore+0x238121c] WebCore::LocalFrameView::~LocalFrameView()+0x68
C [WebCore+0x2381f2c] WebCore::LocalFrameView::~LocalFrameView()+0x10
C [WebCore+0x14d5c8] WebCore::CachedFrame::clear()+0xc0
C [WebCore+0x14d2dc] WebCore::CachedFrame::destroy()+0x37c
C [WebCore+0x14cebc] WebCore::CachedPage::~CachedPage()+0x24
Temporary fix, so it should no longer crash from the JavaDoc: disable the hover tooltips (Preferences -> Java -> Editor -> Hovers -> Untick Combined Hover)
Temporary fix, so it should no longer crash from the JavaDoc: disable the hover tooltips (Preferences -> Java -> Editor -> Hovers -> Untick Combined Hover)
Seems to be the only course of action.
I guess we need to figure out if the crash is only happening with the Javadoc hover popups or in other uses of WebKit on Mac. I'm testing a simple Browser component snippet and can't make it crash.
- This is only happening since Sequoia 15.4 released on March 31 2025
- Crashing on Eclipse since at least 4.32 (I didn’t test older versions) and on latest 4.35
- Seems to be triggered by Javadoc hover popups with scrollbars
- Having the Javadoc View open at the same time might be a factor (it exacerbates the problem, but the crash can occur without it being open)
- Is this only happening in Javadoc hover popups, or in other uses of Webkit?
- Is this an Apple bug or WebKit bug?
- Is this something that can be fixed in SWT or Javadoc popup code?
It might be worth opening an issue at WebKit. But I don't know if they might throw it back to SWT/JDT UI/another component here. As this only seems to be triggered when using Javadoc hover popups it might be something that could be worked around in that component.
Could someone advise on best course of action?
@jschmied As you are the original issue reporter, do you think you might open an issue at WebKit?
https://bugs.webkit.org/show_bug.cgi?id=290985
https://bugs.webkit.org/show_bug.cgi?id=290985
Thanks! Perhaps you could add a link to this report there?
Thanks! Perhaps you could add a link to this report there?
I think the link is already there
I think the link is already there
Yes, it is now. Thanks @jschmied
Our primary macOS team at SAP has filed an incident with Apple regarding this issue. We received feedback from them that they are currently working on a solution. Here’s a quote from the incident that I obtained from my colleague:
I confirmed our engineering team is aware of this issue and I expect it will be addressed in an upcoming software update. I will follow up once we have more information.
Hopefully, the version 15.4.1 (or however it will be called) will be released as soon as possible.
The bug at https://bugs.webkit.org/show_bug.cgi?id=290985 has been changed to a "Security" issue. This means that it's not accessible to anyone not on the cc list. I'm on the cc list of the bug and the last response was a pull request from an Apple engineer on 4 April.
Thanks for the update - please keep us informed.
Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix
Thanks for that - most helpful.
On 9 Apr 2025, at 17:10, Jürgen Schmied @.***> wrote:
jschmied left a comment (eclipse-platform/eclipse.platform.swt#1978) Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
https://github.com/eclipse-platform/eclipse.platform.swt/issues/1978#issuecomment-2790229135 https://github.com/notifications/unsubscribe-auth/AE4Z2TRNA5A564AZ7AU2AOL2YVA6BAVCNFSM6AAAAAB2JAOYXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGIZDSMJTGU
jschmied left a comment (eclipse-platform/eclipse.platform.swt#1978) https://github.com/eclipse-platform/eclipse.platform.swt/issues/1978#issuecomment-2790229135 Workaround is to switch off Java->Editors->Hover-> "combined hover" until we get a bugfix
— Reply to this email directly, view it on GitHub https://github.com/eclipse-platform/eclipse.platform.swt/issues/1978#issuecomment-2790229135, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4Z2TRNA5A564AZ7AU2AOL2YVA6BAVCNFSM6AAAAAB2JAOYXGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGIZDSMJTGU. You are receiving this because you are subscribed to this thread.
I guess we need to figure out if the crash is only happening with the Javadoc hover popups or in other uses of WebKit on Mac. I'm testing a simple Browser component snippet and can't make it crash.
I'm seeing the same (or very similar) crash when editing TypeScript (Wild Web Developer with generic code editor). Unfortunately, I can't work out exactly what is causing the crash, but it is every few 10s of seconds :-(. The stack trace is similar to above so hopefully the same cause. It only started with the update to Sequoia 15.4.
I'm having this issue and, while otherwise sporadic, I can trigger it with 100% reproducibility when clicking "Open description of rule" in the hover panel of a Sonarlint/SonarQube issue (in both JavaScript or Java code)
The description pane opens momentarily with content partially rendered before Eclipse closes. Nothing is registered in the Eclipse error log
Nothing is registered in the Eclipse error log
If you navigate to the location of the eclipse executable (for me this is in Eclipse.app/Contents/MacOS/) you'll find a crash log there.
Nothing is registered in the Eclipse error log
If you navigate to the location of the
eclipseexecutable (for me this is inEclipse.app/Contents/MacOS/) you'll find a crash log there.
Gotcha - thanks. Stacktrace shows pretty much the same as the OP and your logs, and indeed points to Webkit's scrollbar calcs
C [WebCore+0x1dbe5e8] WebCore::BackForwardCache::markPagesForContentsSizeChanged(WebCore::Page&)+0xe4
C [WebCore+0x2382364] WebCore::LocalFrameView::setContentsSize(WebCore::IntSize const&)+0x104
C [WebCore+0x238318c] WebCore::LocalFrameView::adjustViewSize()+0x60
C [WebCore+0x23a0b7c] WebCore::LocalFrameViewLayoutContext::performLayout(bool)+0x660
C [WebCore+0x2385ff8] WebCore::LocalFrameViewLayoutContext::layout(bool)+0x3c
C [WebKitLegacy+0x106d0] -[WebHTMLView layoutToMinimumPageWidth:height:originalPageWidth:originalPageHeight:maximumShrinkRatio:adjustingViewSize:]+0xf0
C [WebKitLegacy+0xcf0c] -[WebDynamicScrollBarsView(WebInternal) updateScrollers]+0x88
Just a heads up that the crash is still happening in macOS Sequoia 15.4.1 released today.
Just a heads up that the crash is still happening in macOS Sequoia 15.4.1 released today.
Yes, we received confirmation from Apple that 15.4.1 does not include any WebKit fixes. Similarly, 15.5 beta 1 or 2 also lacks a fix. Apple appears to anticipate a fix in the next beta or the one after that, unless there are any unforeseen circumstances.
@Phillipus: Since you can still access the WebKit bug - Can you see/observe any information about the root cause of the issue? For our tooling, the workaround ‘disable combined hover’ is not applicable, and we are actively seeking an alternative solution.
Last change on webkit bug on 2025-04-04, no further information.
@Phillipus: Since you can still access the WebKit bug - Can you see/observe any information about the root cause of the issue? For our tooling, the workaround ‘disable combined hover’ is not applicable, and we are actively seeking an alternative solution.
As @jschmied says, the last update was on 2025-04-04 with a pull request from an Apple Engineer. Other than that and an assigned internal Radar number there's no commentary on the issue.
Unfortunately 15.5 beta 3 (24F5053j) does not appear to contain a fix.
I don't know if a lack of activity on the Webkit bug suggests that a fix has not yet been implemented. Does anyone have an Apple contact who can confirm whether or not the fix will make it into 15.5?