From mcatanzaro at redhat.com  Mon Apr  1 14:18:36 2024
From: mcatanzaro at redhat.com (Michael Catanzaro)
Date: Mon, 01 Apr 2024 16:18:36 -0500
Subject: [webkit-dev] ASSERT vs. RELEASE_ASSERT
Message-ID: <0J8ABS.K6MDZWP72L1D@redhat.com>

Hi,

Just brainstorming, but I generally think it's worth enabling way more 
assertions in production builds to the extent we can do so without 
unacceptable performance impact. My ideal would be to rename ASSERT() 
to SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make 
release asserts the "default" type of assert. But I'm not ambitious 
enough to attempt that. Notably, this would in many cases downgrade the 
severity of security bugs, since hitting a RELEASE_ASSERT() is at worst 
a denial of service issue. Curious what other WebKit developers think 
about this.

Michael



From pgriffis at igalia.com  Mon Apr  1 16:28:07 2024
From: pgriffis at igalia.com (Patrick Griffis)
Date: Mon, 01 Apr 2024 18:28:07 -0500
Subject: [webkit-dev] ASSERT vs. RELEASE_ASSERT
In-Reply-To: <0J8ABS.K6MDZWP72L1D@redhat.com>
References: <0J8ABS.K6MDZWP72L1D@redhat.com>
Message-ID: <1ab07c353106e9aec9a4a93b88191a01@igalia.com>

On 2024-04-01 16:18, Michael Catanzaro via webkit-dev wrote:
> Hi,
> 
> Just brainstorming, but I generally think it's worth enabling way more assertions in production builds to the extent we can do so without unacceptable performance impact. My ideal would be to rename ASSERT() to SLOW_ASSERT() and then rename RELEASE_ASSERT() to ASSERT(), to make release asserts the "default" type of assert. But I'm not ambitious enough to attempt that. Notably, this would in many cases downgrade the severity of security bugs, since hitting a RELEASE_ASSERT() is at worst a denial of service issue. Curious what other WebKit developers think about this.
> 
> Michael

I'm not suggesting this has the same result as what you propose but I
think it's worth mentioning the CMake build supports `-DENABLE_ASSERTS`
on Release builds now and this was always possible on macOS.

From brandonstewart at apple.com  Wed Apr  3 19:47:05 2024
From: brandonstewart at apple.com (Brandon Stewart)
Date: Wed, 03 Apr 2024 21:47:05 -0500
Subject: [webkit-dev] Lost docs!
In-Reply-To: <V7ZWAS.L041OLLDXBS13@redhat.com>
References: <V7ZWAS.L041OLLDXBS13@redhat.com>
Message-ID: <D9F660F3-B7DB-49C2-BE7B-C7301731C48F@apple.com>

I did copy the documentation over a year ago, but anything added there since then would be missing on docs.webkit.org <http://docs.webkit.org/>.

The document you pointed out hasn?t been ported yet, so it would be good to copy that as well.

I tried to get most of the relevant documentation from trac too, but I am sure there might have been a few things I missed.

Brandon

> On Mar 25, 2024, at 12:28?PM, Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> Hi,
> 
> I've noticed we have a bunch of documentation on https://github.com/WebKit/WebKit/wiki that has not been migrated to https://docs.webkit.org/index.html. Some of the documentation looks pretty important, e.g. [1]. In the case of this specific page, we can probably just copy/paste it onto the bottom of [2] or similiar; it's easy to move since it's Markdown in either place. We should think about what to do with the other pages, though.
> 
> Michael
> 
> [1] https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Guidelines
> [2] https://docs.webkit.org/Deep%20Dive/MemoryManagement.html
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240403/6b5d9ffa/attachment.htm>

From mcatanzaro at redhat.com  Thu Apr  4 05:45:42 2024
From: mcatanzaro at redhat.com (Michael Catanzaro)
Date: Thu, 04 Apr 2024 07:45:42 -0500
Subject: [webkit-dev] Lost docs!
In-Reply-To: <D9F660F3-B7DB-49C2-BE7B-C7301731C48F@apple.com>
References: <V7ZWAS.L041OLLDXBS13@redhat.com>
 <D9F660F3-B7DB-49C2-BE7B-C7301731C48F@apple.com>
Message-ID: <6S4FBS.U0Z8U5J4EVPK3@redhat.com>

On Wed, Apr 3 2024 at 09:47:05 PM -05:00:00, Brandon Stewart 
<brandonstewart at apple.com> wrote:
> I did copy the documentation over a year ago, but anything added 
> there since then would be missing on docs.webkit.org.

Perhaps we should just turn off the wiki to prevent more stuff from 
being added by mistake? Anybody still need the GitHub wiki? It's really 
best to have just one place for our docs.



From max.schmitt at microsoft.com  Mon Apr  8 01:04:54 2024
From: max.schmitt at microsoft.com (Max Schmitt)
Date: Mon, 8 Apr 2024 08:04:54 +0000
Subject: [webkit-dev] [EXTERNAL] Re:  Lost docs!
In-Reply-To: <6S4FBS.U0Z8U5J4EVPK3@redhat.com>
References: <V7ZWAS.L041OLLDXBS13@redhat.com>
 <D9F660F3-B7DB-49C2-BE7B-C7301731C48F@apple.com>
 <6S4FBS.U0Z8U5J4EVPK3@redhat.com>
Message-ID: <DBBPR83MB0562635151AB6CE0FF5E70A8E7002@DBBPR83MB0562.EURPRD83.prod.outlook.com>

Would it be also possible to redirect the webkit.org build instructions<https://webkit.org/webkit-on-windows/> for Windows over to the docs.webkit.org build instructions<https://docs.webkit.org/Ports/WindowsPort.html>? Since they are getting more and more outdated.

Thanks,

Max
________________________________
From: Michael Catanzaro via webkit-dev <webkit-dev at lists.webkit.org>
Sent: Thursday, April 4, 2024 2:45 PM
To: Brandon Stewart <brandonstewart at apple.com>
Cc: webkit-dev at lists.webkit.org <webkit-dev at lists.webkit.org>
Subject: [EXTERNAL] Re: [webkit-dev] Lost docs!

On Wed, Apr 3 2024 at 09:47:05 PM -05:00:00, Brandon Stewart
<brandonstewart at apple.com> wrote:
> I did copy the documentation over a year ago, but anything added
> there since then would be missing on docs.webkit.org.

Perhaps we should just turn off the wiki to prevent more stuff from
being added by mistake? Anybody still need the GitHub wiki? It's really
best to have just one place for our docs.


_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.webkit.org%2Fmailman%2Flistinfo%2Fwebkit-dev&data=05%7C02%7Cmax.schmitt%40microsoft.com%7C5374fe722fe24095285708dc54a554ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638478316310746385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KjAC7J55jvRKpS2U9uXdHhZ2zAx5fNTL0TtSMhgWhTc%3D&reserved=0<https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240408/12882536/attachment.htm>

From stevie.glass at gmail.com  Tue Apr 16 15:01:45 2024
From: stevie.glass at gmail.com (Steve Glass)
Date: Wed, 17 Apr 2024 08:01:45 +1000
Subject: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build
 on Mac
Message-ID: <CADC0ay1eBvQpk3j0e2Wb8PFyX7h=3dv1Lnfph+J_vSVuGKBAjQ@mail.gmail.com>

Hi,

Hi, I?m trying to build jsc on my M1 Mac following the instructions at
> https://trac.webkit.org/wiki/JSCOnly and https://webkit
> .org/getting-started/ .
> However when I run the built binary it exits immediately with a bus error
> which lldb shows to be EXC_BAD_ACCESS.


I'm also trying to build JSC on my M1 Mac and my experience is the *exact* same
error as Laurence has reported above.

When I run I get a bus error at the same location in the code:

[27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug
> lldb WebKitBuild/JSCOnly/Debug/bin/jsc
> (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
> (arm64).
> (lldb) target create Web
> Available completions:
> WebKitBuild/
> WebDriverTests/
> WebKit.xcworkspace/
> WebKitLibraries/
> Websites/
> (lldb) target create WebKitBuild/JSCOnly/Debug/b
> Available completions:
> WebKitBuild/JSCOnly/Debug/bmalloc/
> WebKitBuild/JSCOnly/Debug/bin/
> WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
> (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc
> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
> (arm64).
> (lldb) run
> Process 86562 launched: '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
> (arm64)
> Process 86562 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x133804000)
>     frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove
> + 168
> libsystem_platform.dylib`:
> ->  0x18696f248 <+168>: stp    q2, q3, [x0]
>     0x18696f24c <+172>: subs   x2, x2, #0x40
>     0x18696f250 <+176>: b.ls   0x18696f26c               ; <+204>
>     0x18696f254 <+180>: stp    q0, q1, [x3]
> Target 1: (jsc) stopped.
>

This is what 'image list' reports at this point:


> (lldb) image list
> [  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0000000100000000
> /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc
> [  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x00000001865b0000
> /usr/lib/dyld
> [  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x000000010781c000
> /Users/stevie/git/WebKit
> /WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
> [  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x00000001d1096000
> /usr/lib/libedit.3.dylib
> [  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x00000001b06d7000
> /usr/lib/libncurses.5.4.dylib
> [  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x00000001935ae000
> /usr/lib/libSystem.B.dylib
> [  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x00000001935a8000
> /usr/lib/system/libcache.dylib
> [  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x0000000193563000
> /usr/lib/system/libcommonCrypto.dylib
> [  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x000000019358f000
> /usr/lib/system/libcompiler_rt.dylib
> [  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x0000000193585000
> /usr/lib/system/libcopyfile.dylib
> [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x00000001866a4000
> /usr/lib/system/libcorecrypto.dylib
> [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x000000018678a000
> /usr/lib/system/libdispatch.dylib
> [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x0000000186945000
> /usr/lib/system/libdyld.dylib
> [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x000000019359e000
> /usr/lib/system/libkeymgr.dylib
> [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x000000019353b000
> /usr/lib/system/libmacho.dylib
> [ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x0000000192a1c000
> /usr/lib/system/libquarantine.dylib
> [ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x000000019359b000
> /usr/lib/system/libremovefile.dylib
> [ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x000000018c0bc000
> /usr/lib/system/libsystem_asl.dylib
> [ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x0000000186639000
> /usr/lib/system/libsystem_blocks.dylib
> [ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x00000001867d5000
> /usr/lib/system/libsystem_c.dylib
> [ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x0000000193593000
> /usr/lib/system/libsystem_collections.dylib
> [ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x0000000191bf6000
> /usr/lib/system/libsystem_configuration.dylib
> [ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x0000000190c34000
> /usr/lib/system/libsystem_containermanager.dylib
> [ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x00000001931d2000
> /usr/lib/system/libsystem_coreservices.dylib
> [ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x0000000189d5b000
> /usr/lib/system/libsystem_darwin.dylib
> [ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x000000024d32a000
> /usr/lib/system/libsystem_darwindirectory.dylib
> [ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x000000019359f000
> /usr/lib/system/libsystem_dnssd.dylib
> [ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x000000024d32e000
> /usr/lib/system/libsystem_eligibility.dylib
> [ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x00000001867d2000
> /usr/lib/system/libsystem_featureflags.dylib
> [ 29] 615EAFA2-4446-3994-89E9-858A0552F1B8 0x0000000186973000
> /usr/lib/system/libsystem_info.dylib
> [ 30] 9735ABAE-2939-30EB-90D4-C6F23F795B2F 0x0000000193500000
> /usr/lib/system/libsystem_m.dylib
> [ 31] B36EAAD5-558D-39E8-AB0D-FD87F2EF154B 0x000000018674d000
> /usr/lib/system/libsystem_malloc.dylib
> [ 32] EBACF63D-8B18-37FF-8952-85FD99605BD7 0x000000018c02a000
> /usr/lib/system/libsystem_networkextension.dylib
> [ 33] EDCEB984-2FC8-3EB5-9016-3453A3DDEE8F 0x000000018a1d1000
> /usr/lib/system/libsystem_notify.dylib
> [ 34] 2F95044C-6CEF-3731-B1B9-F7D6A51B3A3F 0x0000000191bfb000
> /usr/lib/system/libsystem_sandbox.dylib
> [ 35] EEA82D78-5036-3A22-8DC6-4E131A57941B 0x000000024d332000
> /usr/lib/system/libsystem_sanitizers.dylib
> [ 36] 11D0DCC2-FC9F-3E2C-B2CF-0662E64DC96D 0x0000000193598000
> /usr/lib/system/libsystem_secinit.dylib
> [ 37] 2A91FD2C-4CEF-3211-A025-7A1C0A8C2DB5 0x00000001868fd000
> /usr/lib/system/libsystem_kernel.dylib
> [ 38] 031F3E8C-5227-3138-A444-68174C1C28CF 0x000000018696b000
> /usr/lib/system/libsystem_platform.dylib
> [ 39] 45239F06-CC53-36D0-9933-7776AC7EA2FA 0x0000000186938000
> /usr/lib/system/libsystem_pthread.dylib
> [ 40] 372ACDF1-29E7-34DA-B035-BD7671EB5A8B 0x000000018daaa000
> /usr/lib/system/libsystem_symptoms.dylib
> [ 41] 681EBF40-B321-364A-88EA-04AB45E3DA66 0x0000000186689000
> /usr/lib/system/libsystem_trace.dylib
> [ 42] 31BBAE83-7FFD-30A6-8BFC-6D5D17A6CC82 0x0000000193571000
> /usr/lib/system/libunwind.dylib
> [ 43] C43D5322-9B69-37EE-B51E-45FDE5D81B5B 0x000000018663e000
> /usr/lib/system/libxpc.dylib
> [ 44] 4FED965B-18AD-3A4F-8928-1F0A3C35345F 0x00000001868e1000
> /usr/lib/libc++abi.dylib
> [ 45] 76C8305C-4066-390C-8F3E-F0858D756AD8 0x0000000186560000
> /usr/lib/libobjc.A.dylib
> [ 46] 3FE71C4F-17CC-3B93-AE29-05CE7D116F1B 0x000000019357d000
> /usr/lib/liboah.dylib
> [ 47] 08C4329E-407F-310B-B037-75A8020B2963 0x0000000186854000
> /usr/lib/libc++.1.dylib
> [ 48] 50DE7E22-A040-3E0F-836E-BEF36B36EC01 0x0000000189a94000
> /usr/lib/libicucore.A.dylib
> (lldb)


...and the backtrace at the point of crash looks like this:

(lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x133804000)
>   * frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove
> + 168
>     frame #1: 0x000000010798f984 JavaScriptCore`JSC::performJITMemcpy(dst=0x0000000133804000,
> src=0x00000001010300c0, n=64) at ExecutableAllocator.h:147:12
>     frame #2: 0x000000010797ef60 JavaScriptCore`void
> JSC::LinkBuffer::copyCompactAndLinkCode<unsigned
> int>(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40,
> effort=JITCompilationMustSucceed) at LinkBuffer.cpp:433:9
>     frame #3: 0x000000010797e1c4 JavaScriptCore`JSC::LinkBuffer::linkCode(this=0x000000016fdfeb60,
> macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at
> LinkBuffer.cpp:475:5
>     frame #4: 0x00000001079bee10 JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60,
> macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff,
> profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:117:9
>     frame #5: 0x0000000108a0c29c JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60,
> macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff,
> profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:116:5
>     frame #6: 0x0000000108ec280c JavaScriptCore`JSC::LLInt::defaultCallThunk()::$_14::operator()(this=0x000000016fdfef17)
> const at LLIntThunks.cpp:340:20
>     frame #7: 0x0000000108ec2718 JavaScriptCore`decltype(std::declval<JSC::LLInt::defaultCallThunk()::$_14>()())
> std::__1::__invoke[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__f=0x000000016fdfef17)
> at invoke.h:340:25
>     frame #8: 0x0000000108ec26f4 JavaScriptCore`void
> std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::__execute[abi:un170006]<>(this=0x000000016fdfeed0,
> (null)=__tuple_indices<> @ 0x000000016fdfee2f) at mutex:632:9
>     frame #9: 0x0000000108ec26c8 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::operator()[abi:un170006](this=0x000000016fdfeed0)
> at mutex:624:9
>     frame #10: 0x0000000108ec25c8 JavaScriptCore`void
> std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>(__vp=0x000000016fdfeed0)
> at mutex:660:5
>     frame #11: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned
> long volatile&, void*, void (*)(void*)) + 180
>     frame #12: 0x0000000108eb4ce0 JavaScriptCore`void
> std::__1::call_once[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__flag=0x000000010ae2af68,
> __func=0x000000016fdfef17) at mutex:677:9
>     frame #13: 0x0000000108e9b704 JavaScriptCore`JSC::LLInt::defaultCallThunk()
> at LLIntThunks.cpp:309:5
>     frame #14: 0x0000000108e9a9b8 JavaScriptCore`JSC::LLInt::defaultCall()
> at LLIntEntrypoint.cpp:198:16
>     frame #15: 0x0000000108e9a87c JavaScriptCore`JSC::LLInt::initialize()
> at LLIntData.cpp:264:36
>     frame #16: 0x00000001091ba7b8 JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x000000016fdff0ff)
> const at InitializeThreading.cpp:121:9
>     frame #17: 0x00000001091ba6c0 JavaScriptCore`decltype(std::declval<JSC::initialize()::$_12>()())
> std::__1::__invoke[abi:un170006]<JSC::initialize()::$_12>(__f=0x000000016fdff0ff)
> at invoke.h:340:25
>     frame #18: 0x00000001091ba69c JavaScriptCore`void
> std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::__execute[abi:un170006]<>(this=0x000000016fdff0c0,
> (null)=__tuple_indices<> @ 0x000000016fdff01f) at mutex:632:9
>     frame #19: 0x00000001091ba670 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::operator()[abi:un170006](this=0x000000016fdff0c0)
> at mutex:624:9
>     frame #20: 0x00000001091ba570 JavaScriptCore`void
> std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::initialize()::$_12&&>>(__vp=0x000000016fdff0c0)
> at mutex:660:5
>     frame #21: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned
> long volatile&, void*, void (*)(void*)) + 180
>     frame #22: 0x0000000109191860 JavaScriptCore`void
> std::__1::call_once[abi:un170006]<JSC::initialize()::$_12>(__flag=0x000000010ae2b7f0,
> __func=0x000000016fdff0ff) at mutex:677:9
>     frame #23: 0x00000001091917f4 JavaScriptCore`JSC::initialize() at
> InitializeThreading.cpp:73:5
>     frame #24: 0x000000010000987c jsc`jscmain(argc=1,
> argv=0x000000016fdff440) at jsc.cpp:4361:5
>     frame #25: 0x0000000100009680 jsc`main(argc=1,
> argv=0x000000016fdff440) at jsc.cpp:3541:15
>     frame #26: 0x00000001865b60e0 dyld`start + 2360
> (lldb)


My software versions are different to those reported by Laurence:

  Versions:

    - WebKit main (9dc3f9d6339)
    - Xcode 15.3 (15E204a)
    - macOS 14.4.1
    - CMake.app 3.24.4

I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests
--jsc-only --debug --no-build --no-fail-fast' and it is reporting bus
errors everywhere. I've tried pulling newer versions of webkit but this
error has persisted for the last couple of weeks.

Thanks

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240417/6f66671e/attachment.htm>

From ap at webkit.org  Mon Apr 22 08:53:04 2024
From: ap at webkit.org (=?UTF-8?Q?Alexey_Proskuryakov?=)
Date: Mon, 22 Apr 2024 15:53:04 +0000
Subject: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build
 on Mac
In-Reply-To: <CADC0ay1eBvQpk3j0e2Wb8PFyX7h=3dv1Lnfph+J_vSVuGKBAjQ@mail.gmail.com>
References: <CADC0ay1eBvQpk3j0e2Wb8PFyX7h=3dv1Lnfph+J_vSVuGKBAjQ@mail.gmail.com>
 <1FE14EEC-B4D1-4874-9532-F29403F29AE1@webkit.org>
Message-ID: <0101018f0682c442-206be538-0da9-4865-bdc4-71b06d1e3541-000000@us-west-2.amazonses.com>

+ Keith for visibility

16 ???. 2024??., ? 3:01?PM, Steve Glass via webkit-dev <webkit-dev at lists.webkit.org> ???????(?):

Hi,

Hi, I?m trying to build jsc on my M1 Mac following the instructions at
https://trac.webkit.org/wiki/JSCOnly?and?https://webkit.org/getting-started/?.
However when I run the built binary it exits immediately with a bus error
which lldb shows to be EXC_BAD_ACCESS.
I'm also trying to build JSC on my M1 Mac and my experience is the?exact?same error as Laurence has reported above.

When I run I get a bus error at the same location in the code:

[27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug lldb WebKitBuild/JSCOnly/Debug/bin/jsc?
(lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb)?target create Web
Available completions:
WebKitBuild/? ? ? ?
WebDriverTests/?? ?
WebKit.xcworkspace/
WebKitLibraries/? ?
Websites/?? ? ? ? ?
(lldb)?target create WebKitBuild/JSCOnly/Debug/b
Available completions:
WebKitBuild/JSCOnly/Debug/bmalloc/?? ? ? ? ? ? ? ?
WebKitBuild/JSCOnly/Debug/bin/?? ? ? ? ? ? ? ? ? ?
WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
(lldb)?target create WebKitBuild/JSCOnly/Debug/bin/jsc?
Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
(lldb)?run
Process 86562 launched: '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
Process 86562 stopped
* thread #1, queue =?'com.apple.main-thread', stop reason =?EXC_BAD_ACCESS (code=2, address=0x133804000)
? ??frame #0:?0x000000018696f248?libsystem_platform.dylib`_platform_memmove + 168
libsystem_platform.dylib`:
->??0x18696f248 <+168>: stp? ??q2, q3, [x0]
? ??0x18696f24c <+172>: subs???x2, x2, #0x40
? ??0x18696f250 <+176>:?b.ls <http://b.ls/> ???0x18696f26c?? ? ? ? ? ? ??; <+204>
? ??0x18696f254 <+180>: stp? ??q0, q1, [x3]
Target 1: (jsc) stopped.

This is what 'image list' reports at this point:
?(lldb)?image list
[??0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0000000100000000 /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc?
[??1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x00000001865b0000 /usr/lib/dyld?
[??2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x000000010781c000 /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore?
[??3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x00000001d1096000 /usr/lib/libedit.3.dylib?
[??4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x00000001b06d7000 /usr/lib/libncurses.5.4.dylib?
[??5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x00000001935ae000 /usr/lib/libSystem.B.dylib?
[??6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x00000001935a8000 /usr/lib/system/libcache.dylib?
[??7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x0000000193563000 /usr/lib/system/libcommonCrypto.dylib?
[??8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x000000019358f000 /usr/lib/system/libcompiler_rt.dylib?
[??9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x0000000193585000 /usr/lib/system/libcopyfile.dylib?
[ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x00000001866a4000 /usr/lib/system/libcorecrypto.dylib?
[ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x000000018678a000 /usr/lib/system/libdispatch.dylib?
[ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x0000000186945000 /usr/lib/system/libdyld.dylib?
[ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x000000019359e000 /usr/lib/system/libkeymgr.dylib?
[ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x000000019353b000 /usr/lib/system/libmacho.dylib?
[ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x0000000192a1c000 /usr/lib/system/libquarantine.dylib?
[ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x000000019359b000 /usr/lib/system/libremovefile.dylib?
[ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x000000018c0bc000 /usr/lib/system/libsystem_asl.dylib?
[ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x0000000186639000 /usr/lib/system/libsystem_blocks.dylib?
[ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x00000001867d5000 /usr/lib/system/libsystem_c.dylib?
[ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x0000000193593000 /usr/lib/system/libsystem_collections.dylib?
[ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x0000000191bf6000 /usr/lib/system/libsystem_configuration.dylib?
[ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x0000000190c34000 /usr/lib/system/libsystem_containermanager.dylib?
[ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x00000001931d2000 /usr/lib/system/libsystem_coreservices.dylib?
[ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x0000000189d5b000 /usr/lib/system/libsystem_darwin.dylib?
[ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x000000024d32a000 /usr/lib/system/libsystem_darwindirectory.dylib?
[ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x000000019359f000 /usr/lib/system/libsystem_dnssd.dylib?
[ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x000000024d32e000 /usr/lib/system/libsystem_eligibility.dylib?
[ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x00000001867d2000 /usr/lib/system/libsystem_featureflags.dylib?
[ 29] 615EAFA2-4446-3994-89E9-858A0552F1B8 0x0000000186973000 /usr/lib/system/libsystem_info.dylib?
[ 30] 9735ABAE-2939-30EB-90D4-C6F23F795B2F 0x0000000193500000 /usr/lib/system/libsystem_m.dylib?
[ 31] B36EAAD5-558D-39E8-AB0D-FD87F2EF154B 0x000000018674d000 /usr/lib/system/libsystem_malloc.dylib?
[ 32] EBACF63D-8B18-37FF-8952-85FD99605BD7 0x000000018c02a000 /usr/lib/system/libsystem_networkextension.dylib?
[ 33] EDCEB984-2FC8-3EB5-9016-3453A3DDEE8F 0x000000018a1d1000 /usr/lib/system/libsystem_notify.dylib?
[ 34] 2F95044C-6CEF-3731-B1B9-F7D6A51B3A3F 0x0000000191bfb000 /usr/lib/system/libsystem_sandbox.dylib?
[ 35] EEA82D78-5036-3A22-8DC6-4E131A57941B 0x000000024d332000 /usr/lib/system/libsystem_sanitizers.dylib?
[ 36] 11D0DCC2-FC9F-3E2C-B2CF-0662E64DC96D 0x0000000193598000 /usr/lib/system/libsystem_secinit.dylib?
[ 37] 2A91FD2C-4CEF-3211-A025-7A1C0A8C2DB5 0x00000001868fd000 /usr/lib/system/libsystem_kernel.dylib?
[ 38] 031F3E8C-5227-3138-A444-68174C1C28CF 0x000000018696b000 /usr/lib/system/libsystem_platform.dylib?
[ 39] 45239F06-CC53-36D0-9933-7776AC7EA2FA 0x0000000186938000 /usr/lib/system/libsystem_pthread.dylib?
[ 40] 372ACDF1-29E7-34DA-B035-BD7671EB5A8B 0x000000018daaa000 /usr/lib/system/libsystem_symptoms.dylib?
[ 41] 681EBF40-B321-364A-88EA-04AB45E3DA66 0x0000000186689000 /usr/lib/system/libsystem_trace.dylib?
[ 42] 31BBAE83-7FFD-30A6-8BFC-6D5D17A6CC82 0x0000000193571000 /usr/lib/system/libunwind.dylib?
[ 43] C43D5322-9B69-37EE-B51E-45FDE5D81B5B 0x000000018663e000 /usr/lib/system/libxpc.dylib?
[ 44] 4FED965B-18AD-3A4F-8928-1F0A3C35345F 0x00000001868e1000 /usr/lib/libc++abi.dylib?
[ 45] 76C8305C-4066-390C-8F3E-F0858D756AD8 0x0000000186560000 /usr/lib/libobjc.A.dylib?
[ 46] 3FE71C4F-17CC-3B93-AE29-05CE7D116F1B 0x000000019357d000 /usr/lib/liboah.dylib?
[ 47] 08C4329E-407F-310B-B037-75A8020B2963 0x0000000186854000 /usr/lib/libc++.1.dylib?
[ 48] 50DE7E22-A040-3E0F-836E-BEF36B36EC01 0x0000000189a94000 /usr/lib/libicucore.A.dylib?
(lldb)?

...and the backtrace at the point of crash looks like this:

(lldb)?bt
* thread #1, queue =?'com.apple.main-thread', stop reason =?EXC_BAD_ACCESS (code=2, address=0x133804000)
??* frame #0:?0x000000018696f248?libsystem_platform.dylib`_platform_memmove + 168
? ??frame #1:?0x000000010798f984?JavaScriptCore`JSC::performJITMemcpy(dst=0x0000000133804000, src=0x00000001010300c0, n=64) at?ExecutableAllocator.h:147:12
? ??frame #2:?0x000000010797ef60?JavaScriptCore`void JSC::LinkBuffer::copyCompactAndLinkCode<unsigned int>(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at?LinkBuffer.cpp:433:9
? ??frame #3:?0x000000010797e1c4?JavaScriptCore`JSC::LinkBuffer::linkCode(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at?LinkBuffer.cpp:475:5
? ??frame #4:?0x00000001079bee10?JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, profile=Thunk, effort=JITCompilationMustSucceed) at?LinkBuffer.h:117:9
? ??frame #5:?0x0000000108a0c29c?JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, profile=Thunk, effort=JITCompilationMustSucceed) at?LinkBuffer.h:116:5
? ??frame #6:?0x0000000108ec280c?JavaScriptCore`JSC::LLInt::defaultCallThunk()::$_14::operator()(this=0x000000016fdfef17) const at?LLIntThunks.cpp:340:20
? ??frame #7:?0x0000000108ec2718?JavaScriptCore`decltype(std::declval<JSC::LLInt::defaultCallThunk()::$_14>()()) std::__1::__invoke[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__f=0x000000016fdfef17) at?invoke.h:340:25
? ??frame #8:?0x0000000108ec26f4?JavaScriptCore`void std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::__execute[abi:un170006]<>(this=0x000000016fdfeed0, (null)=__tuple_indices<> @ 0x000000016fdfee2f) at?mutex:632:9
? ??frame #9:?0x0000000108ec26c8?JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::operator()[abi:un170006](this=0x000000016fdfeed0) at?mutex:624:9
? ??frame #10:?0x0000000108ec25c8?JavaScriptCore`void std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>(__vp=0x000000016fdfeed0) at?mutex:660:5
? ??frame #11:?0x000000018686ae44?libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 180
? ??frame #12:?0x0000000108eb4ce0?JavaScriptCore`void std::__1::call_once[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__flag=0x000000010ae2af68, __func=0x000000016fdfef17) at?mutex:677:9
? ??frame #13:?0x0000000108e9b704?JavaScriptCore`JSC::LLInt::defaultCallThunk() at?LLIntThunks.cpp:309:5
? ??frame #14:?0x0000000108e9a9b8?JavaScriptCore`JSC::LLInt::defaultCall() at?LLIntEntrypoint.cpp:198:16
? ??frame #15:?0x0000000108e9a87c?JavaScriptCore`JSC::LLInt::initialize() at?LLIntData.cpp:264:36
? ??frame #16:?0x00000001091ba7b8?JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x000000016fdff0ff) const at?InitializeThreading.cpp:121:9
? ??frame #17:?0x00000001091ba6c0?JavaScriptCore`decltype(std::declval<JSC::initialize()::$_12>()()) std::__1::__invoke[abi:un170006]<JSC::initialize()::$_12>(__f=0x000000016fdff0ff) at?invoke.h:340:25
? ??frame #18:?0x00000001091ba69c?JavaScriptCore`void std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::__execute[abi:un170006]<>(this=0x000000016fdff0c0, (null)=__tuple_indices<> @ 0x000000016fdff01f) at?mutex:632:9
? ??frame #19:?0x00000001091ba670?JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::operator()[abi:un170006](this=0x000000016fdff0c0) at?mutex:624:9

? ??frame #20:?0x00000001091ba570?JavaScriptCore`void std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::initialize()::$_12&&>>(__vp=0x000000016fdff0c0) at?mutex:660:5
? ??frame #21:?0x000000018686ae44?libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 180
? ??frame #22:?0x0000000109191860?JavaScriptCore`void std::__1::call_once[abi:un170006]<JSC::initialize()::$_12>(__flag=0x000000010ae2b7f0, __func=0x000000016fdff0ff) at?mutex:677:9
? ??frame #23:?0x00000001091917f4?JavaScriptCore`JSC::initialize() at?InitializeThreading.cpp:73:5
? ??frame #24:?0x000000010000987c?jsc`jscmain(argc=1, argv=0x000000016fdff440) at?jsc.cpp:4361:5
? ??frame #25:?0x0000000100009680?jsc`main(argc=1, argv=0x000000016fdff440) at?jsc.cpp:3541:15
? ??frame #26:?0x00000001865b60e0?dyld`start + 2360
(lldb)?

My software versions are different to those reported by Laurence:

? Versions:

? ? -?WebKit?main (9dc3f9d6339)
? ? - Xcode 15.3 (15E204a)
? ? - macOS 14.4.1
? ? - CMake.app 3.24.4

I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests --jsc-only --debug --no-build --no-fail-fast' and it is reporting bus errors everywhere. I've tried pulling newer versions of?webkit?but this error has persisted for the last couple of weeks.

Thanks

Steve
_______________________________________________
webkit-dev mailing list
webkit-dev at lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240422/145275ff/attachment.htm>

From keith_miller at apple.com  Mon Apr 22 11:35:10 2024
From: keith_miller at apple.com (Keith Miller)
Date: Mon, 22 Apr 2024 14:35:10 -0400
Subject: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build
 on Mac
In-Reply-To: <0101018f0682c442-206be538-0da9-4865-bdc4-71b06d1e3541-000000@us-west-2.amazonses.com>
References: <CADC0ay1eBvQpk3j0e2Wb8PFyX7h=3dv1Lnfph+J_vSVuGKBAjQ@mail.gmail.com>
 <1FE14EEC-B4D1-4874-9532-F29403F29AE1@webkit.org>
 <0101018f0682c442-206be538-0da9-4865-bdc4-71b06d1e3541-000000@us-west-2.amazonses.com>
Message-ID: <3436ED81-2186-4C40-B305-6DDC15E14D4D@apple.com>

Hi folks, 

Looks like this happened during our adoption of the BrowserEngine API. I have a PR to fix it https://github.com/WebKit/WebKit/pull/27587

There was also an unrelated build breakage for the JSCOnly port, which I also fixed in that PR.

Cheers,
Keith

> On Apr 22, 2024, at 11:53?AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 
> + Keith for visibility
> 
>> 16 ???. 2024??., ? 3:01?PM, Steve Glass via webkit-dev <webkit-dev at lists.webkit.org> ???????(?):
>> 
>> Hi,
>> 
>>> Hi, I?m trying to build jsc on my M1 Mac following the instructions at
>>> https://trac.webkit.org/wiki/JSCOnly and https://webkit.org/getting-started/ .
>>> However when I run the built binary it exits immediately with a bus error
>>> which lldb shows to be EXC_BAD_ACCESS.
>> 
>> I'm also trying to build JSC on my M1 Mac and my experience is the exact same error as Laurence has reported above.
>> 
>> When I run I get a bus error at the same location in the code:
>> 
>>> [27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug lldb WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
>>> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
>>> (lldb) target create Web
>>> Available completions:
>>> 	WebKitBuild/       
>>> 	WebDriverTests/    
>>> 	WebKit.xcworkspace/
>>> 	WebKitLibraries/   
>>> 	Websites/          
>>> (lldb) target create WebKitBuild/JSCOnly/Debug/b
>>> Available completions:
>>> 	WebKitBuild/JSCOnly/Debug/bmalloc/                
>>> 	WebKitBuild/JSCOnly/Debug/bin/                    
>>> 	WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
>>> (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64).
>>> (lldb) run
>>> Process 86562 launched: '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc' (arm64)
>>> Process 86562 stopped
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x133804000)
>>>     frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove + 168
>>> libsystem_platform.dylib`:
>>> ->  0x18696f248 <+168>: stp    q2, q3, [x0]
>>>     0x18696f24c <+172>: subs   x2, x2, #0x40
>>>     0x18696f250 <+176>: b.ls <http://b.ls/>   0x18696f26c               ; <+204>
>>>     0x18696f254 <+180>: stp    q0, q1, [x3]
>>> Target 1: (jsc) stopped.
>> 
>> This is what 'image list' reports at this point:
>>  
>>> (lldb) image list
>>> [  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0000000100000000 /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc 
>>> [  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x00000001865b0000 /usr/lib/dyld 
>>> [  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x000000010781c000 /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore 
>>> [  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x00000001d1096000 /usr/lib/libedit.3.dylib 
>>> [  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x00000001b06d7000 /usr/lib/libncurses.5.4.dylib 
>>> [  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x00000001935ae000 /usr/lib/libSystem.B.dylib 
>>> [  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x00000001935a8000 /usr/lib/system/libcache.dylib 
>>> [  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x0000000193563000 /usr/lib/system/libcommonCrypto.dylib 
>>> [  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x000000019358f000 /usr/lib/system/libcompiler_rt.dylib 
>>> [  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x0000000193585000 /usr/lib/system/libcopyfile.dylib 
>>> [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x00000001866a4000 /usr/lib/system/libcorecrypto.dylib 
>>> [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x000000018678a000 /usr/lib/system/libdispatch.dylib 
>>> [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x0000000186945000 /usr/lib/system/libdyld.dylib 
>>> [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x000000019359e000 /usr/lib/system/libkeymgr.dylib 
>>> [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x000000019353b000 /usr/lib/system/libmacho.dylib 
>>> [ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x0000000192a1c000 /usr/lib/system/libquarantine.dylib 
>>> [ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x000000019359b000 /usr/lib/system/libremovefile.dylib 
>>> [ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x000000018c0bc000 /usr/lib/system/libsystem_asl.dylib 
>>> [ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x0000000186639000 /usr/lib/system/libsystem_blocks.dylib 
>>> [ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x00000001867d5000 /usr/lib/system/libsystem_c.dylib 
>>> [ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x0000000193593000 /usr/lib/system/libsystem_collections.dylib 
>>> [ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x0000000191bf6000 /usr/lib/system/libsystem_configuration.dylib 
>>> [ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x0000000190c34000 /usr/lib/system/libsystem_containermanager.dylib 
>>> [ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x00000001931d2000 /usr/lib/system/libsystem_coreservices.dylib 
>>> [ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x0000000189d5b000 /usr/lib/system/libsystem_darwin.dylib 
>>> [ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x000000024d32a000 /usr/lib/system/libsystem_darwindirectory.dylib 
>>> [ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x000000019359f000 /usr/lib/system/libsystem_dnssd.dylib 
>>> [ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x000000024d32e000 /usr/lib/system/libsystem_eligibility.dylib 
>>> [ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x00000001867d2000 /usr/lib/system/libsystem_featureflags.dylib 
>>> [ 29] 615EAFA2-4446-3994-89E9-858A0552F1B8 0x0000000186973000 /usr/lib/system/libsystem_info.dylib 
>>> [ 30] 9735ABAE-2939-30EB-90D4-C6F23F795B2F 0x0000000193500000 /usr/lib/system/libsystem_m.dylib 
>>> [ 31] B36EAAD5-558D-39E8-AB0D-FD87F2EF154B 0x000000018674d000 /usr/lib/system/libsystem_malloc.dylib 
>>> [ 32] EBACF63D-8B18-37FF-8952-85FD99605BD7 0x000000018c02a000 /usr/lib/system/libsystem_networkextension.dylib 
>>> [ 33] EDCEB984-2FC8-3EB5-9016-3453A3DDEE8F 0x000000018a1d1000 /usr/lib/system/libsystem_notify.dylib 
>>> [ 34] 2F95044C-6CEF-3731-B1B9-F7D6A51B3A3F 0x0000000191bfb000 /usr/lib/system/libsystem_sandbox.dylib 
>>> [ 35] EEA82D78-5036-3A22-8DC6-4E131A57941B 0x000000024d332000 /usr/lib/system/libsystem_sanitizers.dylib 
>>> [ 36] 11D0DCC2-FC9F-3E2C-B2CF-0662E64DC96D 0x0000000193598000 /usr/lib/system/libsystem_secinit.dylib 
>>> [ 37] 2A91FD2C-4CEF-3211-A025-7A1C0A8C2DB5 0x00000001868fd000 /usr/lib/system/libsystem_kernel.dylib 
>>> [ 38] 031F3E8C-5227-3138-A444-68174C1C28CF 0x000000018696b000 /usr/lib/system/libsystem_platform.dylib 
>>> [ 39] 45239F06-CC53-36D0-9933-7776AC7EA2FA 0x0000000186938000 /usr/lib/system/libsystem_pthread.dylib 
>>> [ 40] 372ACDF1-29E7-34DA-B035-BD7671EB5A8B 0x000000018daaa000 /usr/lib/system/libsystem_symptoms.dylib 
>>> [ 41] 681EBF40-B321-364A-88EA-04AB45E3DA66 0x0000000186689000 /usr/lib/system/libsystem_trace.dylib 
>>> [ 42] 31BBAE83-7FFD-30A6-8BFC-6D5D17A6CC82 0x0000000193571000 /usr/lib/system/libunwind.dylib 
>>> [ 43] C43D5322-9B69-37EE-B51E-45FDE5D81B5B 0x000000018663e000 /usr/lib/system/libxpc.dylib 
>>> [ 44] 4FED965B-18AD-3A4F-8928-1F0A3C35345F 0x00000001868e1000 /usr/lib/libc++abi.dylib 
>>> [ 45] 76C8305C-4066-390C-8F3E-F0858D756AD8 0x0000000186560000 /usr/lib/libobjc.A.dylib 
>>> [ 46] 3FE71C4F-17CC-3B93-AE29-05CE7D116F1B 0x000000019357d000 /usr/lib/liboah.dylib 
>>> [ 47] 08C4329E-407F-310B-B037-75A8020B2963 0x0000000186854000 /usr/lib/libc++.1.dylib 
>>> [ 48] 50DE7E22-A040-3E0F-836E-BEF36B36EC01 0x0000000189a94000 /usr/lib/libicucore.A.dylib 
>>> (lldb) 
>> 
>> ...and the backtrace at the point of crash looks like this:
>> 
>>> (lldb) bt
>>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x133804000)
>>>   * frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove + 168
>>>     frame #1: 0x000000010798f984 JavaScriptCore`JSC::performJITMemcpy(dst=0x0000000133804000, src=0x00000001010300c0, n=64) at ExecutableAllocator.h:147:12
>>>     frame #2: 0x000000010797ef60 JavaScriptCore`void JSC::LinkBuffer::copyCompactAndLinkCode<unsigned int>(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at LinkBuffer.cpp:433:9
>>>     frame #3: 0x000000010797e1c4 JavaScriptCore`JSC::LinkBuffer::linkCode(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at LinkBuffer.cpp:475:5
>>>     frame #4: 0x00000001079bee10 JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:117:9
>>>     frame #5: 0x0000000108a0c29c JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff, profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:116:5
>>>     frame #6: 0x0000000108ec280c JavaScriptCore`JSC::LLInt::defaultCallThunk()::$_14::operator()(this=0x000000016fdfef17) const at LLIntThunks.cpp:340:20
>>>     frame #7: 0x0000000108ec2718 JavaScriptCore`decltype(std::declval<JSC::LLInt::defaultCallThunk()::$_14>()()) std::__1::__invoke[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__f=0x000000016fdfef17) at invoke.h:340:25
>>>     frame #8: 0x0000000108ec26f4 JavaScriptCore`void std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::__execute[abi:un170006]<>(this=0x000000016fdfeed0, (null)=__tuple_indices<> @ 0x000000016fdfee2f) at mutex:632:9
>>>     frame #9: 0x0000000108ec26c8 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::operator()[abi:un170006](this=0x000000016fdfeed0) at mutex:624:9
>>>     frame #10: 0x0000000108ec25c8 JavaScriptCore`void std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>(__vp=0x000000016fdfeed0) at mutex:660:5
>>>     frame #11: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 180
>>>     frame #12: 0x0000000108eb4ce0 JavaScriptCore`void std::__1::call_once[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__flag=0x000000010ae2af68, __func=0x000000016fdfef17) at mutex:677:9
>>>     frame #13: 0x0000000108e9b704 JavaScriptCore`JSC::LLInt::defaultCallThunk() at LLIntThunks.cpp:309:5
>>>     frame #14: 0x0000000108e9a9b8 JavaScriptCore`JSC::LLInt::defaultCall() at LLIntEntrypoint.cpp:198:16
>>>     frame #15: 0x0000000108e9a87c JavaScriptCore`JSC::LLInt::initialize() at LLIntData.cpp:264:36
>>>     frame #16: 0x00000001091ba7b8 JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x000000016fdff0ff) const at InitializeThreading.cpp:121:9
>>>     frame #17: 0x00000001091ba6c0 JavaScriptCore`decltype(std::declval<JSC::initialize()::$_12>()()) std::__1::__invoke[abi:un170006]<JSC::initialize()::$_12>(__f=0x000000016fdff0ff) at invoke.h:340:25
>>>     frame #18: 0x00000001091ba69c JavaScriptCore`void std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::__execute[abi:un170006]<>(this=0x000000016fdff0c0, (null)=__tuple_indices<> @ 0x000000016fdff01f) at mutex:632:9
>>>     frame #19: 0x00000001091ba670 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::operator()[abi:un170006](this=0x000000016fdff0c0) at mutex:624:9
>>>     frame #20: 0x00000001091ba570 JavaScriptCore`void std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::initialize()::$_12&&>>(__vp=0x000000016fdff0c0) at mutex:660:5
>>>     frame #21: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 180
>>>     frame #22: 0x0000000109191860 JavaScriptCore`void std::__1::call_once[abi:un170006]<JSC::initialize()::$_12>(__flag=0x000000010ae2b7f0, __func=0x000000016fdff0ff) at mutex:677:9
>>>     frame #23: 0x00000001091917f4 JavaScriptCore`JSC::initialize() at InitializeThreading.cpp:73:5
>>>     frame #24: 0x000000010000987c jsc`jscmain(argc=1, argv=0x000000016fdff440) at jsc.cpp:4361:5
>>>     frame #25: 0x0000000100009680 jsc`main(argc=1, argv=0x000000016fdff440) at jsc.cpp:3541:15
>>>     frame #26: 0x00000001865b60e0 dyld`start + 2360
>>> (lldb) 
>> 
>> 
>> My software versions are different to those reported by Laurence:
>> 
>>   Versions:
>> 
>>     - WebKit main (9dc3f9d6339)
>>     - Xcode 15.3 (15E204a)
>>     - macOS 14.4.1
>>     - CMake.app 3.24.4
>> 
>> I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests --jsc-only --debug --no-build --no-fail-fast' and it is reporting bus errors everywhere. I've tried pulling newer versions of webkit but this error has persisted for the last couple of weeks.
>> 
>> Thanks
>> 
>> Steve
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240422/1c31ef47/attachment.htm>

From jbedard at apple.com  Tue Apr 23 12:41:14 2024
From: jbedard at apple.com (Jonathan Bedard)
Date: Tue, 23 Apr 2024 12:41:14 -0700
Subject: [webkit-dev] Sam Sneddon is now a WebKit Reviewer
Message-ID: <8CE40DAC-8307-4234-8976-2843E42C3F15@apple.com>

Hello folks,

I am happy to announce that Sam Sneddon is now a WebKit Reviewer!

Sam is an expert in Web Platform Tests and our tooling to run layout tests, along with Python in general.

Jonathan Bedard

From stevie.glass at gmail.com  Thu Apr 25 16:32:38 2024
From: stevie.glass at gmail.com (Steve Glass)
Date: Fri, 26 Apr 2024 09:32:38 +1000
Subject: [webkit-dev] jsc bus error EXC_BAD_ACCESS with jsc-only build
 on Mac
In-Reply-To: <3436ED81-2186-4C40-B305-6DDC15E14D4D@apple.com>
References: <CADC0ay1eBvQpk3j0e2Wb8PFyX7h=3dv1Lnfph+J_vSVuGKBAjQ@mail.gmail.com>
 <1FE14EEC-B4D1-4874-9532-F29403F29AE1@webkit.org>
 <0101018f0682c442-206be538-0da9-4865-bdc4-71b06d1e3541-000000@us-west-2.amazonses.com>
 <3436ED81-2186-4C40-B305-6DDC15E14D4D@apple.com>
Message-ID: <CADC0ay3E8CzEYb9ejGafCxUodsjDs2snZJXgQkHg39zGh1dAOQ@mail.gmail.com>

Hi Keith

I can confirm this fixed this problem.

All the best

Steve

On Tue, 23 Apr 2024 at 04:35, Keith Miller <keith_miller at apple.com> wrote:

> Hi folks,
>
> Looks like this happened during our adoption of the BrowserEngine API. I
> have a PR to fix it https://github.com/WebKit/WebKit/pull/27587
>
> There was also an unrelated build breakage for the JSCOnly port, which I
> also fixed in that PR.
>
> Cheers,
> Keith
>
> On Apr 22, 2024, at 11:53?AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> + Keith for visibility
>
> 16 ???. 2024??., ? 3:01?PM, Steve Glass via webkit-dev <
> webkit-dev at lists.webkit.org> ???????(?):
>
> Hi,
>
> Hi, I?m trying to build jsc on my M1 Mac following the instructions at
>> https://trac.webkit.org/wiki/JSCOnly and https://webkit
>> .org/getting-started/ .
>> However when I run the built binary it exits immediately with a bus error
>> which lldb shows to be EXC_BAD_ACCESS.
>
>
> I'm also trying to build JSC on my M1 Mac and my experience is the *exact* same
> error as Laurence has reported above.
>
> When I run I get a bus error at the same location in the code:
>
> [27467]>DYLD_FRAMEWORK_PATH=/users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug
>> lldb WebKitBuild/JSCOnly/Debug/bin/jsc
>> (lldb) target create "WebKitBuild/JSCOnly/Debug/bin/jsc"
>> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64).
>> (lldb) target create Web
>> Available completions:
>> WebKitBuild/
>> WebDriverTests/
>> WebKit.xcworkspace/
>> WebKitLibraries/
>> Websites/
>> (lldb) target create WebKitBuild/JSCOnly/Debug/b
>> Available completions:
>> WebKitBuild/JSCOnly/Debug/bmalloc/
>> WebKitBuild/JSCOnly/Debug/bin/
>> WebKitBuild/JSCOnly/Debug/build-webkit-options.txt
>> (lldb) target create WebKitBuild/JSCOnly/Debug/bin/jsc
>> Current executable set to '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64).
>> (lldb) run
>> Process 86562 launched: '/Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc'
>> (arm64)
>> Process 86562 stopped
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=2, address=0x133804000)
>>     frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove
>> + 168
>> libsystem_platform.dylib`:
>> ->  0x18696f248 <+168>: stp    q2, q3, [x0]
>>     0x18696f24c <+172>: subs   x2, x2, #0x40
>>     0x18696f250 <+176>: b.ls   0x18696f26c               ; <+204>
>>     0x18696f254 <+180>: stp    q0, q1, [x3]
>> Target 1: (jsc) stopped.
>>
>
> This is what 'image list' reports at this point:
>
>
>> (lldb) image list
>> [  0] 7A464963-87D0-342F-BF0D-B030FC8488D4 0x0000000100000000
>> /Users/stevie/git/WebKit/WebKitBuild/JSCOnly/Debug/bin/jsc
>> [  1] F6DD3EC2-85A4-3AB1-8486-B189CD980EBE 0x00000001865b0000
>> /usr/lib/dyld
>> [  2] BDD21D2C-3C16-3379-9501-D64F8AFA3C0E 0x000000010781c000
>> /Users/stevie/git/WebKit
>> /WebKitBuild/JSCOnly/Debug/lib/JavaScriptCore.framework/Versions/1.0.0/JavaScriptCore
>> [  3] A356C2AE-08AC-30C6-B3D2-89535B87B958 0x00000001d1096000
>> /usr/lib/libedit.3.dylib
>> [  4] 27A49F84-CD29-3448-BE8C-ED4240A78C9C 0x00000001b06d7000
>> /usr/lib/libncurses.5.4.dylib
>> [  5] BE250157-7A2B-39DA-B404-983D7989DFC6 0x00000001935ae000
>> /usr/lib/libSystem.B.dylib
>> [  6] C0BCBAE5-4913-3D80-8E3A-9D4DEC1EA827 0x00000001935a8000
>> /usr/lib/system/libcache.dylib
>> [  7] 0BA453ED-E5A2-3C2F-86F4-CFCFFA6C1879 0x0000000193563000
>> /usr/lib/system/libcommonCrypto.dylib
>> [  8] DE476BC5-36E2-3F7A-87C8-1EF2BE6ADFDA 0x000000019358f000
>> /usr/lib/system/libcompiler_rt.dylib
>> [  9] 3DF60503-459B-3DA5-BD91-E72518FA9370 0x0000000193585000
>> /usr/lib/system/libcopyfile.dylib
>> [ 10] 95C1D199-1B36-32B2-9BE7-5723A58D0D96 0x00000001866a4000
>> /usr/lib/system/libcorecrypto.dylib
>> [ 11] 7F973554-8168-35BF-AE86-2E9123E81BF7 0x000000018678a000
>> /usr/lib/system/libdispatch.dylib
>> [ 12] 72199A80-9C55-376D-8ECF-EE68AFA57B7A 0x0000000186945000
>> /usr/lib/system/libdyld.dylib
>> [ 13] 291CFCDE-CF87-3F39-A3E3-36C4303BEC16 0x000000019359e000
>> /usr/lib/system/libkeymgr.dylib
>> [ 14] DD2A9F47-7F80-344C-B6FE-82682F8AAB4A 0x000000019353b000
>> /usr/lib/system/libmacho.dylib
>> [ 15] 158A39C2-F9C6-32CA-845B-F1DFB711718A 0x0000000192a1c000
>> /usr/lib/system/libquarantine.dylib
>> [ 16] 92A7E10F-1F6C-30D5-9C44-D42352D3A674 0x000000019359b000
>> /usr/lib/system/libremovefile.dylib
>> [ 17] B8B21C7C-4530-3EA2-AB35-BA98B82F33D0 0x000000018c0bc000
>> /usr/lib/system/libsystem_asl.dylib
>> [ 18] E9F1A3B9-AE38-3F4C-BF14-8A6E012AD36C 0x0000000186639000
>> /usr/lib/system/libsystem_blocks.dylib
>> [ 19] 49477E07-E77B-332F-B98D-79CA210A866D 0x00000001867d5000
>> /usr/lib/system/libsystem_c.dylib
>> [ 20] 2EA02C23-E13C-39AE-B850-82CEABACE7A6 0x0000000193593000
>> /usr/lib/system/libsystem_collections.dylib
>> [ 21] D57D8736-2800-3066-82D4-C433A2DC10C4 0x0000000191bf6000
>> /usr/lib/system/libsystem_configuration.dylib
>> [ 22] C9DB5B40-6F90-348A-A518-3ACFB49B39FE 0x0000000190c34000
>> /usr/lib/system/libsystem_containermanager.dylib
>> [ 23] 324A6A0A-BBDE-3257-9A75-6A74C85E3430 0x00000001931d2000
>> /usr/lib/system/libsystem_coreservices.dylib
>> [ 24] 8DB1E11F-85AB-3699-AD96-228BE7D8C715 0x0000000189d5b000
>> /usr/lib/system/libsystem_darwin.dylib
>> [ 25] 0395D567-DBD9-3F03-A9E0-A0969963A834 0x000000024d32a000
>> /usr/lib/system/libsystem_darwindirectory.dylib
>> [ 26] 4D030E4B-27FC-3C22-8467-A8CAFECA7761 0x000000019359f000
>> /usr/lib/system/libsystem_dnssd.dylib
>> [ 27] 6C663441-D4D5-361C-ABE7-B68D7B6E5B9B 0x000000024d32e000
>> /usr/lib/system/libsystem_eligibility.dylib
>> [ 28] D8AF5585-B9E4-38C0-B48B-CFD5C13DEB82 0x00000001867d2000
>> /usr/lib/system/libsystem_featureflags.dylib
>> [ 29] 615EAFA2-4446-3994-89E9-858A0552F1B8 0x0000000186973000
>> /usr/lib/system/libsystem_info.dylib
>> [ 30] 9735ABAE-2939-30EB-90D4-C6F23F795B2F 0x0000000193500000
>> /usr/lib/system/libsystem_m.dylib
>> [ 31] B36EAAD5-558D-39E8-AB0D-FD87F2EF154B 0x000000018674d000
>> /usr/lib/system/libsystem_malloc.dylib
>> [ 32] EBACF63D-8B18-37FF-8952-85FD99605BD7 0x000000018c02a000
>> /usr/lib/system/libsystem_networkextension.dylib
>> [ 33] EDCEB984-2FC8-3EB5-9016-3453A3DDEE8F 0x000000018a1d1000
>> /usr/lib/system/libsystem_notify.dylib
>> [ 34] 2F95044C-6CEF-3731-B1B9-F7D6A51B3A3F 0x0000000191bfb000
>> /usr/lib/system/libsystem_sandbox.dylib
>> [ 35] EEA82D78-5036-3A22-8DC6-4E131A57941B 0x000000024d332000
>> /usr/lib/system/libsystem_sanitizers.dylib
>> [ 36] 11D0DCC2-FC9F-3E2C-B2CF-0662E64DC96D 0x0000000193598000
>> /usr/lib/system/libsystem_secinit.dylib
>> [ 37] 2A91FD2C-4CEF-3211-A025-7A1C0A8C2DB5 0x00000001868fd000
>> /usr/lib/system/libsystem_kernel.dylib
>> [ 38] 031F3E8C-5227-3138-A444-68174C1C28CF 0x000000018696b000
>> /usr/lib/system/libsystem_platform.dylib
>> [ 39] 45239F06-CC53-36D0-9933-7776AC7EA2FA 0x0000000186938000
>> /usr/lib/system/libsystem_pthread.dylib
>> [ 40] 372ACDF1-29E7-34DA-B035-BD7671EB5A8B 0x000000018daaa000
>> /usr/lib/system/libsystem_symptoms.dylib
>> [ 41] 681EBF40-B321-364A-88EA-04AB45E3DA66 0x0000000186689000
>> /usr/lib/system/libsystem_trace.dylib
>> [ 42] 31BBAE83-7FFD-30A6-8BFC-6D5D17A6CC82 0x0000000193571000
>> /usr/lib/system/libunwind.dylib
>> [ 43] C43D5322-9B69-37EE-B51E-45FDE5D81B5B 0x000000018663e000
>> /usr/lib/system/libxpc.dylib
>> [ 44] 4FED965B-18AD-3A4F-8928-1F0A3C35345F 0x00000001868e1000
>> /usr/lib/libc++abi.dylib
>> [ 45] 76C8305C-4066-390C-8F3E-F0858D756AD8 0x0000000186560000
>> /usr/lib/libobjc.A.dylib
>> [ 46] 3FE71C4F-17CC-3B93-AE29-05CE7D116F1B 0x000000019357d000
>> /usr/lib/liboah.dylib
>> [ 47] 08C4329E-407F-310B-B037-75A8020B2963 0x0000000186854000
>> /usr/lib/libc++.1.dylib
>> [ 48] 50DE7E22-A040-3E0F-836E-BEF36B36EC01 0x0000000189a94000
>> /usr/lib/libicucore.A.dylib
>> (lldb)
>
>
> ...and the backtrace at the point of crash looks like this:
>
> (lldb) bt
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=2, address=0x133804000)
>>   * frame #0: 0x000000018696f248 libsystem_platform.dylib`_platform_memmove
>> + 168
>>     frame #1: 0x000000010798f984 JavaScriptCore`JSC::performJITMemcpy(dst=0x0000000133804000,
>> src=0x00000001010300c0, n=64) at ExecutableAllocator.h:147:12
>>     frame #2: 0x000000010797ef60 JavaScriptCore`void
>> JSC::LinkBuffer::copyCompactAndLinkCode<unsigned
>> int>(this=0x000000016fdfeb60, macroAssembler=0x000000016fdfec40,
>> effort=JITCompilationMustSucceed) at LinkBuffer.cpp:433:9
>>     frame #3: 0x000000010797e1c4 JavaScriptCore`JSC::LinkBuffer::linkCode(this=0x000000016fdfeb60,
>> macroAssembler=0x000000016fdfec40, effort=JITCompilationMustSucceed) at
>> LinkBuffer.cpp:475:5
>>     frame #4: 0x00000001079bee10 JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60,
>> macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff,
>> profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:117:9
>>     frame #5: 0x0000000108a0c29c JavaScriptCore`JSC::LinkBuffer::LinkBuffer(this=0x000000016fdfeb60,
>> macroAssembler=0x000000016fdfec40, ownerUID=0xffffffffffffffff,
>> profile=Thunk, effort=JITCompilationMustSucceed) at LinkBuffer.h:116:5
>>     frame #6: 0x0000000108ec280c JavaScriptCore`JSC::LLInt::defaultCallThunk()::$_14::operator()(this=0x000000016fdfef17)
>> const at LLIntThunks.cpp:340:20
>>     frame #7: 0x0000000108ec2718 JavaScriptCore`decltype(std::declval<JSC::LLInt::defaultCallThunk()::$_14>()())
>> std::__1::__invoke[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__f=0x000000016fdfef17)
>> at invoke.h:340:25
>>     frame #8: 0x0000000108ec26f4 JavaScriptCore`void
>> std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::__execute[abi:un170006]<>(this=0x000000016fdfeed0,
>> (null)=__tuple_indices<> @ 0x000000016fdfee2f) at mutex:632:9
>>     frame #9: 0x0000000108ec26c8 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>::operator()[abi:un170006](this=0x000000016fdfeed0)
>> at mutex:624:9
>>     frame #10: 0x0000000108ec25c8 JavaScriptCore`void
>> std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::LLInt::defaultCallThunk()::$_14&&>>(__vp=0x000000016fdfeed0)
>> at mutex:660:5
>>     frame #11: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned
>> long volatile&, void*, void (*)(void*)) + 180
>>     frame #12: 0x0000000108eb4ce0 JavaScriptCore`void
>> std::__1::call_once[abi:un170006]<JSC::LLInt::defaultCallThunk()::$_14>(__flag=0x000000010ae2af68,
>> __func=0x000000016fdfef17) at mutex:677:9
>>     frame #13: 0x0000000108e9b704 JavaScriptCore`JSC::LLInt::defaultCallThunk()
>> at LLIntThunks.cpp:309:5
>>     frame #14: 0x0000000108e9a9b8 JavaScriptCore`JSC::LLInt::defaultCall()
>> at LLIntEntrypoint.cpp:198:16
>>     frame #15: 0x0000000108e9a87c JavaScriptCore`JSC::LLInt::initialize()
>> at LLIntData.cpp:264:36
>>     frame #16: 0x00000001091ba7b8 JavaScriptCore`JSC::initialize()::$_12::operator()(this=0x000000016fdff0ff)
>> const at InitializeThreading.cpp:121:9
>>     frame #17: 0x00000001091ba6c0 JavaScriptCore`decltype(std::declval<JSC::initialize()::$_12>()())
>> std::__1::__invoke[abi:un170006]<JSC::initialize()::$_12>(__f=0x000000016fdff0ff)
>> at invoke.h:340:25
>>     frame #18: 0x00000001091ba69c JavaScriptCore`void
>> std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::__execute[abi:un170006]<>(this=0x000000016fdff0c0,
>> (null)=__tuple_indices<> @ 0x000000016fdff01f) at mutex:632:9
>>     frame #19: 0x00000001091ba670 JavaScriptCore`std::__1::__call_once_param<std::__1::tuple<JSC::initialize()::$_12&&>>::operator()[abi:un170006](this=0x000000016fdff0c0)
>> at mutex:624:9
>>     frame #20: 0x00000001091ba570 JavaScriptCore`void
>> std::__1::__call_once_proxy[abi:un170006]<std::__1::tuple<JSC::initialize()::$_12&&>>(__vp=0x000000016fdff0c0)
>> at mutex:660:5
>>     frame #21: 0x000000018686ae44 libc++.1.dylib`std::__1::__call_once(unsigned
>> long volatile&, void*, void (*)(void*)) + 180
>>     frame #22: 0x0000000109191860 JavaScriptCore`void
>> std::__1::call_once[abi:un170006]<JSC::initialize()::$_12>(__flag=0x000000010ae2b7f0,
>> __func=0x000000016fdff0ff) at mutex:677:9
>>     frame #23: 0x00000001091917f4 JavaScriptCore`JSC::initialize() at
>> InitializeThreading.cpp:73:5
>>     frame #24: 0x000000010000987c jsc`jscmain(argc=1,
>> argv=0x000000016fdff440) at jsc.cpp:4361:5
>>     frame #25: 0x0000000100009680 jsc`main(argc=1,
>> argv=0x000000016fdff440) at jsc.cpp:3541:15
>>     frame #26: 0x00000001865b60e0 dyld`start + 2360
>> (lldb)
>
>
> My software versions are different to those reported by Laurence:
>
>   Versions:
>
>     - WebKit main (9dc3f9d6339)
>     - Xcode 15.3 (15E204a)
>     - macOS 14.4.1
>     - CMake.app 3.24.4
>
> I run the tests for JSC using 'Tools/Scripts/run-javascriptcore-tests
> --jsc-only --debug --no-build --no-fail-fast' and it is reporting bus
> errors everywhere. I've tried pulling newer versions of webkit but this
> error has persisted for the last couple of weeks.
>
> Thanks
>
> Steve
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20240426/b6075bcd/attachment.htm>

From ysuzuki at apple.com  Tue Apr 30 10:06:15 2024
From: ysuzuki at apple.com (Yusuke Suzuki)
Date: Tue, 30 Apr 2024 10:06:15 -0700
Subject: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl
 exclusively on Windows
Message-ID: <1B66D1FD-D9F5-45EA-9E3A-D93BF1A1F3EB@apple.com>

Hello WebKittens!

Right now, MSVC support is putting significant burden on JavaScriptCore. It lacks many features for JSC development,
as a result, we have so many workarounds for MSVC in JavaScriptCore (For example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot compile it reasonably).

I talked with JSC team and Don at Sony, and now I would like to propose dropping MSVC support on Windows port and using clang-cl exclusively on Windows.

There are many motivating factors for this change.

1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there is zero test coverage on MSVC build right now.
2. On the other hand, EWS is using MSVC for build test. This discrepancy is making maintenance of Windows ports harder and harder.
3. MSVC has various compilation issues which makes JSC lesser quality. Lack of `__builtin_frame_address` support makes JSC bloating JIT code much. CheckedArith has bunch of special code due to lack of overflow-detecting `__builtin_add_overflow` like operations, and so on.  (but TBH, given there is zero coverage, we even don't know whether it is working right now!)
4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are using clang-cl, not MSVC.

Not only solving existing issues, using clang-cl opens significant code / implementation quality improvements opportunities for Windows.

1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use  concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc.
2. This paves a way to make Windows JSC implementation super solid. clang-cl offers sysv-abi feature for function attributes. This allows using Linux / macOS amd64 ABI on certain annotated functions. This basically means that we potentially unify our interpreter and JIT implementations completely in Linux / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super solid, plus, it paves a way to fully enable all JIT tiers on Windows including FTL).

We already discussed with Don and we agreed on this.
And now I would like to formally propose MSVC deprecation towards more cleaner and solid Windows port.

Best regards,
-Yusuke Suzuki

From keith_miller at apple.com  Tue Apr 30 16:43:44 2024
From: keith_miller at apple.com (Keith Miller)
Date: Tue, 30 Apr 2024 16:43:44 -0700
Subject: [webkit-dev] Proposal: Dropping MSVC support and use clang-cl
 exclusively on Windows
In-Reply-To: <1B66D1FD-D9F5-45EA-9E3A-D93BF1A1F3EB@apple.com>
References: <1B66D1FD-D9F5-45EA-9E3A-D93BF1A1F3EB@apple.com>
Message-ID: <8CB6CD8E-E64D-42D9-9080-05BD4A86B60E@apple.com>

+1 

Cheers,
Keith

> On Apr 30, 2024, at 10:06?AM, Yusuke Suzuki via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> Hello WebKittens!
> 
> Right now, MSVC support is putting significant burden on JavaScriptCore. It lacks many features for JSC development,
> as a result, we have so many workarounds for MSVC in JavaScriptCore (For example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot compile it reasonably).
> 
> I talked with JSC team and Don at Sony, and now I would like to propose dropping MSVC support on Windows port and using clang-cl exclusively on Windows.
> 
> There are many motivating factors for this change.
> 
> 1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there is zero test coverage on MSVC build right now.
> 2. On the other hand, EWS is using MSVC for build test. This discrepancy is making maintenance of Windows ports harder and harder.
> 3. MSVC has various compilation issues which makes JSC lesser quality. Lack of `__builtin_frame_address` support makes JSC bloating JIT code much. CheckedArith has bunch of special code due to lack of overflow-detecting `__builtin_add_overflow` like operations, and so on.  (but TBH, given there is zero coverage, we even don't know whether it is working right now!)
> 4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are using clang-cl, not MSVC.
> 
> Not only solving existing issues, using clang-cl opens significant code / implementation quality improvements opportunities for Windows.
> 
> 1. MSVC does not support various C++20 features, so it is putting our C++20 adoption much behind (For example, we cannot use  concept). By using clang-cl, we can start much newer set of C++20 features, improving code quality, static checks etc.
> 2. This paves a way to make Windows JSC implementation super solid. clang-cl offers sysv-abi feature for function attributes. This allows using Linux / macOS amd64 ABI on certain annotated functions. This basically means that we potentially unify our interpreter and JIT implementations completely in Linux / macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super solid, plus, it paves a way to fully enable all JIT tiers on Windows including FTL).
> 
> We already discussed with Don and we agreed on this.
> And now I would like to formally propose MSVC deprecation towards more cleaner and solid Windows port.
> 
> Best regards,
> -Yusuke Suzuki
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev