Bug 248802

Summary:

[GTK] WebKitWebProcess crashes in JavaScriptCore LinkBuffer::copyCompactAndLinkCode

Product:

WebKit

Reporter:

John Ralls <jralls>

Component:

WebKitGTK

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bugs-noreply, mcatanzaro

Priority:

Keywords:

Gtk

Version:

WebKit Local Build

Hardware:

Mac (Apple Silicon)

OS:

macOS 13

Attachments:

Description	Flags
Full stack trace of the crash including the error.	none
Disassembly of platform_memcpy from the lldb debugger.	none
malloc history of the segfaulting address	none
First patch to build webkit on macOS	none
Second patch to build WebKitGtk on macOS.	none
Third patch to build WebKitGtk on macOS.	none

Description John Ralls 2022-12-05 17:59:10 PST

Created attachment 463899 [details]
Full stack trace of the crash including the error.

Apple Silicon native builds. Intel builds do not crash when run on an Apple Silicon Mac using Rosetta2. Although the attached debug information is generated with today's main HEAD (commit 3d71b7e95dde) on macOS 13.1 developer's beta 3 this crash also happens with WebKitGtk 2.32.0 on every version of macOS from 11 on.

Note that there are three patches needed to successfully build WebKitGtk; I'll attach them shortly.

Dependencies are all current git clones from the respective repositories; Gtk is gtk-3-24; most everything else is main/master. Builds are with the [gtk-osx unstable moduleset](https://gitlab.gnome.org/GNOME/gtk-osx/-/tree/master/modulesets-unstable).

Cmake command: cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=$PREFIX -DCMAKE_PREFIX_PATH=$PREFIX -DPORT=GTK -DENABLE_X11_TARGET=OFF -DENABLE_QUARTZ_TARGET=ON -DENABLE_MINIBROWSER=ON -DENABLE_INTROSPECTION=OFF  -DUSE_SYSTEMD=OFF -DENABLE_VIDEO=OFF -DENABLE_WEB_AUDIO=OFF -DENABLE_GEOLOCATION=OFF -DUSE_LIBNOTIFY=OFF -DUSE_LIBHYPHEN=OFF -DUSE_LIBSECRET=OFF -DENABLE_TOUCH_EVENTS=OFF  -DUSE_OPENJPEG=OFF -DUSE_WOFF2=OFF -DUSE_WPE_RENDERER=OFF -DENABLE_GRAPHICS_CONTEXT_GL=OFF -DENABLE_GAMEPAD=OFF -DUSE_APPLE_ICU=NO -DCMAKE_CXX_FLAGS="-stdlib=libc++" -DCMAKE_MACOSX_RPATH=OFF  -DUSE_OPENGL_OR_ES=OFF -DUSE_GBM=OFF -DUSE_AVIF=OFF -DENABLE_JOURNALD_LOG=OFF -DENABLE_DOCUMENTATION=OFF -DUSE_LCMS=OFF -DENABLE_WEBGL=OFF -DENABLE_WEBGL2=OFF

Comment 1 John Ralls 2022-12-05 18:00:14 PST

Created attachment 463900 [details]
Disassembly of platform_memcpy from the lldb debugger.

Comment 2 John Ralls 2022-12-05 18:01:24 PST

Created attachment 463901 [details]
malloc history of the segfaulting address

Comment 3 John Ralls 2022-12-05 18:02:34 PST

Created attachment 463902 [details]
First patch to build webkit on macOS

Comment 4 John Ralls 2022-12-05 18:03:05 PST

Created attachment 463903 [details]
Second patch to build WebKitGtk on macOS.

Comment 5 John Ralls 2022-12-05 18:03:46 PST

Created attachment 463904 [details]
Third patch to build WebKitGtk on macOS.

Comment 6 John Ralls 2022-12-05 18:06:38 PST

This has me stumped because I don't understand why memcpy isn't able to access the address. malloc_history shows it to be in the middle of a huge range of currently allocated memory for the process.

Comment 7 Michael Catanzaro 2022-12-06 06:30:09 PST

Not sure how to help with this bug. Just wanted to say that WebKitGTK is *theoretically* supported on macOS, so you could try to upstream the non-hacky portions of your build fixes if you want.

Comment 8 John Ralls 2022-12-06 09:56:05 PST

(In reply to Michael Catanzaro from comment #7)
> Not sure how to help with this bug. Just wanted to say that WebKitGTK is
> *theoretically* supported on macOS, so you could try to upstream the
> non-hacky portions of your build fixes if you want.

Very little of it is non-hacky because I don't have a deep enough understanding of the code base to do anything but hack. I attached the patches so that someone who does have a better grip on the code could see if I created the problem by doing something dumb.

As for helping, you at least have better knowledge of the code base than I do and more important more contacts with the WebKit team. As I said, I don't even understand why it's crashing: It's a half-gig active allocated memory region into which memcpy wants to write 188 bytes somewhere in the middle. The 188 bytes in the destination are all 0x00. The tail of the address is always 0x4000 so it can't be alignment. Whatever it is it's a problem on aarch64 and not x86_64. What could it be?

Comment 9 Michael Catanzaro 2022-12-06 10:54:58 PST

No clue. Maybe the JSC developers will know.

Comment 10 John Ralls 2024-07-15 18:14:30 PDT

This is fixed by back-porting https://github.com/WebKit/WebKit/commit/34d7f551c40ab7253255304e1443394d5e493333.