Bug 248802

Summary: [GTK] WebKitWebProcess crashes in JavaScriptCore LinkBuffer::copyCompactAndLinkCode
Product: WebKit Reporter: John Ralls <jralls>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: bugs-noreply, mcatanzaro
Priority: P3 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

John Ralls
Reported 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
Attachments
Full stack trace of the crash including the error. (11.75 KB, text/plain)
2022-12-05 17:59 PST, John Ralls 		no flags
Details
Disassembly of platform_memcpy from the lldb debugger. (8.41 KB, text/plain)
2022-12-05 18:00 PST, John Ralls 		no flags
Details
malloc history of the segfaulting address (4.43 KB, text/plain)
2022-12-05 18:01 PST, John Ralls 		no flags
Details
First patch to build webkit on macOS (17.00 KB, text/plain)
2022-12-05 18:02 PST, John Ralls 		no flags
Details
Second patch to build WebKitGtk on macOS. (2.26 KB, text/plain)
2022-12-05 18:03 PST, John Ralls 		no flags
Details
Third patch to build WebKitGtk on macOS. (3.02 KB, text/plain)
2022-12-05 18:03 PST, John Ralls 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
John Ralls
Comment 1 2022-12-05 18:00:14 PST
Created attachment 463900 [details] Disassembly of platform_memcpy from the lldb debugger.
John Ralls
Comment 2 2022-12-05 18:01:24 PST
Created attachment 463901 [details] malloc history of the segfaulting address
John Ralls
Comment 3 2022-12-05 18:02:34 PST
Created attachment 463902 [details] First patch to build webkit on macOS
John Ralls
Comment 4 2022-12-05 18:03:05 PST
Created attachment 463903 [details] Second patch to build WebKitGtk on macOS.
John Ralls
Comment 5 2022-12-05 18:03:46 PST
Created attachment 463904 [details] Third patch to build WebKitGtk on macOS.
John Ralls
Comment 6 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.
Michael Catanzaro
Comment 7 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.
John Ralls
Comment 8 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?
Michael Catanzaro
Comment 9 2022-12-06 10:54:58 PST
No clue. Maybe the JSC developers will know.
John Ralls
Comment 10 2024-07-15 18:14:30 PDT
This is fixed by back-porting https://github.com/WebKit/WebKit/commit/34d7f551c40ab7253255304e1443394d5e493333.
Note You need to log in before you can comment on or make changes to this bug.