WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
271664
[iOS 17.4] Local WebKit builds don't use locally-built app extensions, lldb cannot attach
https://bugs.webkit.org/show_bug.cgi?id=271664
Summary
[iOS 17.4] Local WebKit builds don't use locally-built app extensions, lldb c...
Ali Juma
Reported
2024-03-25 10:57:05 PDT
When building WebKit for the iOS simulator after
276550@main
(so that USE_EXTENSIONKIT is true), local builds try to use app extensions from the simulator runtime rather than their locally-built counterparts. For example, rather than using WebKitBuild/Debug-iphonesimulator/WebContentExtension.appex, local builds instead try to use /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/ExtensionKit/Extensions/WebContentExtension.appex In practice this means that local builds are very broken, since they are combining locally-built WebKit.framework with pre-built app extensions, resulting in mismatching IPC messages. Is there some additional configuration needed to get ExtensionKit builds working with the public SDK?
Attachments
Add attachment
proposed patch, testcase, etc.
Per Arne Vollan
Comment 1
2024-03-26 09:08:54 PDT
(In reply to Ali Juma from
comment #0
)
> When building WebKit for the iOS simulator after
276550@main
(so that > USE_EXTENSIONKIT is true), local builds try to use app extensions from the > simulator runtime rather than their locally-built counterparts. > > For example, rather than using > WebKitBuild/Debug-iphonesimulator/WebContentExtension.appex, local builds > instead try to use > /Library/Developer/CoreSimulator/Volumes/iOS_21E213/Library/Developer/ > CoreSimulator/Profiles/Runtimes/iOS > 17.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/ExtensionKit/ > Extensions/WebContentExtension.appex > > In practice this means that local builds are very broken, since they are > combining locally-built WebKit.framework with pre-built app extensions, > resulting in mismatching IPC messages. > > Is there some additional configuration needed to get ExtensionKit builds > working with the public SDK?
Thanks for reporting this issue! The extension executables themselves are very small executables that just calls into the WebKit framework. What specific issues are you seeing? Since the IPC code is contained in the WebKit framework, I would not immediately expect there to be mismatches with regards to IPC messaging.
Ali Juma
Comment 2
2024-03-26 12:24:44 PDT
(In reply to Per Arne Vollan from
comment #1
)
> Thanks for reporting this issue! > > The extension executables themselves are very small executables that just > calls into the WebKit framework. What specific issues are you seeing?
The main issue is that since these executables are part of the system, SIP prevents attaching a debugger to them, even if they are ultimately calling into the WebKit framework.
> Since > the IPC code is contained in the WebKit framework, I would not immediately > expect there to be mismatches with regards to IPC messaging.
Sometimes on launch, NetworkProcessProxy::didReceiveNetworkProcessProxyMessage receives a WebSWServerConnection_WhenServiceWorkerIsTerminatedForTesting message which it should never receive outside of tests, so fails an assertion for this unhandled message. That made me think that the sender and receiver were using different versions of the MessageName enum, but since this is not consistent it's probably unrelated.
Per Arne Vollan
Comment 3
2024-03-27 08:29:05 PDT
(In reply to Ali Juma from
comment #2
)
> (In reply to Per Arne Vollan from
comment #1
) > > Thanks for reporting this issue! > > > > The extension executables themselves are very small executables that just > > calls into the WebKit framework. What specific issues are you seeing? > > The main issue is that since these executables are part of the system, SIP > prevents attaching a debugger to them, even if they are ultimately calling > into the WebKit framework. >
That is a good point! I will look into ways of resolving this.
> > Since > > the IPC code is contained in the WebKit framework, I would not immediately > > expect there to be mismatches with regards to IPC messaging. > > Sometimes on launch, > NetworkProcessProxy::didReceiveNetworkProcessProxyMessage > receives a WebSWServerConnection_WhenServiceWorkerIsTerminatedForTesting > message which it should never receive outside of tests, so fails an > assertion for this unhandled message. That made me think that the sender and > receiver were using different versions of the MessageName enum, but since > this is not consistent it's probably unrelated.
Radar WebKit Bug Importer
Comment 4
2024-04-01 10:58:15 PDT
<
rdar://problem/125726458
>
Per Arne Vollan
Comment 5
2024-04-09 21:48:41 PDT
*** This bug has been marked as a duplicate of
bug 272401
***
Per Arne Vollan
Comment 6
2024-04-10 11:22:24 PDT
This is still an issue, but the crash you are seeing should be resolved by
https://commits.webkit.org/277304@main
.
Ryosuke Niwa
Comment 7
2024-04-10 17:53:31 PDT
***
Bug 272442
has been marked as a duplicate of this bug. ***
Per Arne Vollan
Comment 8
2024-05-10 09:47:48 PDT
***
Bug 273550
has been marked as a duplicate of this bug. ***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug