[iOS 17.4] Local WebKit builds don't use locally-built app extensions, lldb cannot attach

• Component: WebKit Process Model
• Status: REOPENED ---

[Ali Juma]

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?

[Per Arne Vollan]

(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]

(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]

(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]

<rdar://problem/125726458>

[Per Arne Vollan]

*** This bug has been marked as a duplicate of bug 272401 ***

[Per Arne Vollan]

This is still an issue, but the crash you are seeing should be resolved by  https://commits.webkit.org/277304@main.

[Ryosuke Niwa]

*** Bug 272442 has been marked as a duplicate of this bug. ***

[Per Arne Vollan]

*** Bug 273550 has been marked as a duplicate of this bug. ***