Troubleshooting and solutions for wild pointer issues in Dewu H5 container

1. Background

After the release of Dewu iOS 4.9.x, some h5 pages with horizontal scrolling content have a webkit-related crash that increases rapidly. The crash stack shows that the crash is caused by a wild pointer in the memory during the scrolling animation of UIScrollview.

2. Preliminary investigation

Through the page browsing log, it is found that the pages where the crash occurred are all in the h5 web container, and the crash occurred after the viewDidDisappear method of the page life cycle method was called. Therefore, it is speculated that the crash occurred when the h5 page returned.

A colleague who happened to be in the trading business reproduced the crash and confirmed our speculation. Therefore, we can basically determine that the cause of the crash is that after the page is exited, the page memory is released, but the scrolling animation continues to execute. At this time, the scrollview delegate in the crash stack is not cleared, and the system continues to execute the relevant methods of the delegate, accessing the memory of the released object (wild pointer problem).

At the same time, the h5 pages that crash all have a feature, that is, there is a tab view that can be slid left and right on the page.

There is an experience problem with the side-swipe gesture, and the tab view will scroll when you swipe left or right (see the video below). By correlating the bugly user behavior log, it is determined that this experience problem is related to the crash in this article.

3. Imperfect Solutions

After the above analysis, the repair idea is to disable the horizontal sliding gesture of the tab in the h5 container page when the h5 page is swiped back (at the same time, the gesture needs to be turned on again in the viewWillAppear method of the h5 web container, because the gesture swiping can be canceled when returning to the page).

The specific code is as follows (so that when you slide back the page, the page gesture is disabled and it will not scroll anymore):

 @objc dynamic func webViewCanScroll(enable:Bool) { let contentView = self.webView.scrollView.subviews.first { view in if let className = object_getClass(view), NSStringFromClass(className) == "WKContentView" { return true } return false } let webTouchEventsGestureRecognizer = contentView?.gestureRecognizers?.first(where: { gesture in if let className = object_getClass(gesture), NSStringFromClass(className) == "UIWebTouchEventsGestureRecognizer" { return true } return false }) webTouchEventsGestureRecognizer?.isEnabled = enable } @objc dynamic func webViewCanScroll(enable:Bool) { let contentView = self.webView.scrollView.subviews.first { view in if let className = object_getClass(view), NSStringFromClass(className) == "WKContentView" { return true } return false } let webTouchEventsGestureRecognizer = contentView?.gestureRecognizers?.first(where: { gesture in if let className = object_getClass(gesture), NSStringFromClass(className) == "UIWebTouchEventsGestureRecognizer" { return true } return false }) webTouchEventsGestureRecognizer?.isEnabled = enable }

After testing, the experience problem of the tab page scrolling left and right when the h5 web container slides sideways has indeed been solved. This can solve both the experience problem and the crash problem caused by sliding away from the page, but it does not locate the root cause of the crash. After the repair code was launched, the number of crashes did decrease, but there are still some crashes every day, and feedback has been received about occasional stuck problems under extreme operations on individual pages. Therefore, it is necessary to continue to investigate the root cause of the crash and solve the crash fundamentally.

Continue to look at the crash stack at the beginning of the article. Through the Crash stack, we can determine that the cause of the crash is that the UIScrollview accesses the released memory when calling back the delegate method (see the figure above) during the scrolling animation. The general solution is to clear the UIScrollview's delegate in the dealloc method of the page life cycle after exiting the page. WKWebView does have a scrollVIew property, and we cleared its delegate property in a very early version, but the crash was not resolved.

 deinit { scrollView.delegate = nil scrollView.dataSource = nil } deinit { scrollView.delegate = nil scrollView.dataSource = nil }

Therefore, the Scrollview proxy in the crash stack is not the proxy of the scrollVIew of WKWebView here. So which UIScrollview does the scrollView proxy in the crash stack belong to? Fortunately, Apple's webkit is open source, and we can download the webkit source code to have a look.

4. Find the ScrollViewDelegate in the crash stack

The ScrollViewDelegate in the crash stack is WKScrollingNodeScrollViewDelegate. First, let's take a look at how the WKWebView's scrollview delegate is implemented, because we wonder if there are other delegates for this scrollview besides the ones we set ourselves (such as the WKScrollingNodeScrollViewDelegate in the crash stack).

After studying the Webkit source code, I found the initialization method of scrollview:

 - (void)_setupScrollAndContentViews{ CGRect bounds = self.bounds; _scrollView = adoptNS([[WKScrollView alloc] initWithFrame:bounds]); [_scrollView setInternalDelegate:self]; [_scrollView setBouncesZoom:YES]; } - (void)_setupScrollAndContentViews { CGRect bounds = self.bounds; _scrollView = adoptNS([[WKScrollView alloc] initWithFrame:bounds]); [_scrollView setInternalDelegate:self]; [_scrollView setBouncesZoom:YES]; }

The scrollVIew of WKWebView is of type WKScrollView.

4.1 WKScrollView proxy implementation

First of all, we can see that the type of WKWebView's scrollview is actually WKScrollView (a subclass of UIScrollview). In addition to inheriting the delegate property from the parent class, it also has an internalDelegate property. So is this internalDelegate property the WKScrollingNodeScrollViewDelegate we are looking for?

 @interface WKScrollView : UIScrollView @property (nonatomic, assign) WKWebView <UIScrollViewDelegate> *internalDelegate; @end @interface WKScrollView : UIScrollView @property (nonatomic, assign) WKWebView <UIScrollViewDelegate> *internalDelegate; @end

After reading the source code, I found that this is not the case (the code has been deleted, you can read the source code yourself if you are interested).

 - (void)setInternalDelegate:(WKWebView <UIScrollViewDelegate> *)internalDelegate{ if (internalDelegate == _internalDelegate) return; _internalDelegate = internalDelegate; [self _updateDelegate];} - (void)setDelegate:(id <UIScrollViewDelegate>)delegate{ if (_externalDelegate.get().get() == delegate) return; _externalDelegate = delegate; [self _updateDelegate];} - (id <UIScrollViewDelegate>)delegate{ return _externalDelegate.getAutoreleased();} - (void)_updateDelegate{//...... if (!externalDelegate) else if (!_internalDelegate) else { _delegateForwarder = adoptNS([[WKScrollViewDelegateForwarder alloc] initWithInternalDelegate:_internalDelegate externalDelegate:externalDelegate.get()]); [super setDelegate:_delegateForwarder.get()]; }} - (void)setInternalDelegate:(WKWebView <UIScrollViewDelegate> *)internalDelegate { if (internalDelegate == _internalDelegate) return; _internalDelegate = internalDelegate; [self _updateDelegate]; } - (void)setDelegate:(id <UIScrollViewDelegate>)delegate { if (_externalDelegate.get().get() == delegate) return; _externalDelegate = delegate; [self _updateDelegate]; } - (id <UIScrollViewDelegate>)delegate { return _externalDelegate.getAutoreleased(); } - (void)_updateDelegate {//...... if (!externalDelegate) else if (!_internalDelegate) else { _delegateForwarder = adoptNS([[WKScrollViewDelegateForwarder alloc] initWithInternalDelegate:_internalDelegate externalDelegate:externalDelegate.get()]); [super setDelegate:_delegateForwarder.get()]; } }

The function of this internalDelegate is to let WKWebView listen to the scrollview's scroll callback, and also allow developers to listen to WKWebView's scrollview callback externally. How to achieve this? You can check the implementation of WKScrollViewDelegateForwarder.

 - (void)forwardInvocation:(NSInvocation *)anInvocation{ //... if (internalDelegateWillRespond) [anInvocation invokeWithTarget:_internalDelegate]; if (externalDelegateWillRespond) [anInvocation invokeWithTarget:externalDelegate.get()]; } - (void)forwardInvocation:(NSInvocation *)anInvocation { //... if (internalDelegateWillRespond) [anInvocation invokeWithTarget:_internalDelegate]; if (externalDelegateWillRespond) [anInvocation invokeWithTarget:externalDelegate.get()]; }

This is achieved by overriding the - (void)forwardInvocation:(NSInvocation *)anInvocation method when forwarding a message.

4.2 Conjecture & Verification

Since WKScrollingNodeScrollViewDelegate is not a property of WKScrollview, it means that the scrollview in the crash stack is not WKScrollview, so are there other scrollviews on the page? Let's see where WKScrollingNodeScrollViewDelegate is set in the source code.

 void ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren(const ScrollingStateScrollingNode& scrollingStateNode){ //...... if (scrollingStateNode.hasChangedProperty(ScrollingStateNode::Property::ScrollContainerLayer)) { if (!m_scrollViewDelegate) m_scrollViewDelegate = adoptNS([[WKScrollingNodeScrollViewDelegate alloc] initWithScrollingTreeNodeDelegate:this]); } } void ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren(const ScrollingStateScrollingNode& scrollingStateNode) { //...... if (scrollingStateNode.hasChangedProperty(ScrollingStateNode::Property::ScrollContainerLayer)) { if (!m_scrollViewDelegate) m_scrollViewDelegate = adoptNS([[WKScrollingNodeScrollViewDelegate alloc] initWithScrollingTreeNodeDelegate:this]); } }

Searching the source code of webkit, I found that there is only one place to create WKScrollingNodeScrollViewDelegate. However, the source code of webkit is too complicated, and it is impossible to know which scrollview WKScrollingNodeScrollViewDelegate belongs to by reading the source code.

For this reason, we can only change our thinking. We use Xcode debugging to check whether there are other scrollviews on the page currently loaded by webview.

There happens to be a scrollview on the page: WKChildScrollview

Is this WKChildScrollview the scrollview in the crash stack? If we can determine that its delegate is WKScrollingNodeScrollViewDelegate, it means that this WKChildScrollview is the scrollview in the crash stack.

To verify this conjecture, we first find the source code. There is not much source code and its delegate type cannot be seen.

 @interface WKChildScrollView : UIScrollView <WKContentControlled>@end @interface WKChildScrollView : UIScrollView <WKContentControlled> @end

We can only change our thinking and find the child view of WKWebView whose type is WKChildScrollView at runtime (through OC runtime & view tree traversal), and determine whether its delegate is WKScrollingNodeScrollViewDelegate.

When we find the child view of type WKChildScrollView at runtime, we get its delegate type, which is indeed WKScrollingNodeScrollViewDelegate. So far, we have found the scrollview in the crash stack.

Once the type of scrollview in the crash stack is determined, it is easier to fix it. In the viewDidAppear method of the page life cycle, get the child view of type WKChildScrollView. Then in the dealloc method, set its delegate to null.

 deinit { if self.childScrollView != nil { if self.childScrollView?.delegate != nil { self.childScrollView?.delegate = nil } }} deinit { if self.childScrollView != nil { if self.childScrollView?.delegate != nil { self.childScrollView?.delegate = nil } } }

4.3 Mini Program Same-Layer Rendering

Now that we have figured out the solution, what is WKChildScrollView used for?

WKWebView renders in a layered manner internally. It renders the Compositing Layer generated by the WebKit kernel into a WKCompositingView on iOS, which is a native client View. Unfortunately, the kernel generally renders multiple DOM nodes onto a Compositing Layer, so there is no one-to-one mapping between the Compositing Layer and the DOM node. When the CSS property of a DOM node is set to overflow: scroll (lower versions also need to set -webkit-overflow-scrolling: touch), WKWebView generates a WKChildScrollView for it, which has a mapping relationship with the DOM node. This is a subclass of the native UIScrollView, which means that the scrolling in the WebView is actually carried by the real native scrolling component. WKWebView does this to make the scrolling of the WebView on iOS smoother. Although WKChildScrollView is also a native component, the WebKit kernel has handled the hierarchical relationship between it and other DOM nodes, and this feature can be used for same-layer rendering of mini programs. (As the name suggests, "same-layer rendering" means rendering native components directly to the WebView level through certain technical means. At this time, the "native component layer" no longer exists, and the native components have been directly mounted on the WebView node. You can use "same-layer rendering" native components almost the same way as non-native components, such as using view and image to cover native components, using z-index to specify the level of native components, placing native components in containers such as scroll-view, swiper, movable-view, etc.).

5. Apple’s fix

In a rigorous manner, we wonder what caused the initial crash stack? Was it a function in our development process or a system bug? If it was a system bug, other companies might also encounter it, but there is no information about other companies or developers discussing crashes on the Internet. Let's continue to look at the top function of the crash stack, RemoteScrollingTree::scrollingTreeNodeDidScroll(). The source code is as follows:

 void RemoteScrollingTree::scrollingTreeNodeDidScroll(ScrollingTreeScrollingNode& node, ScrollingLayerPositionAction scrollingLayerPositionAction){ ASSERT(isMainRunLoop()); ScrollingTree::scrollingTreeNodeDidScroll(node, scrollingLayerPositionAction); if (!m_scrollingCoordinatorProxy) return; std::optional<FloatPoint> layoutViewportOrigin; if (is<ScrollingTreeFrameScrollingNode>(node)) layoutViewportOrigin = downcast<ScrollingTreeFrameScrollingNode>(node).layoutViewport().location(); m_scrollingCoordinatorProxy->scrollingTreeNodeDidScroll(node.scrollingNodeID(), node.currentScrollPosition(), layoutViewportOrigin, scrollingLayerPositionAction);} void RemoteScrollingTree::scrollingTreeNodeDidScroll(ScrollingTreeScrollingNode& node, ScrollingLayerPositionAction scrollingLayerPositionAction) { ASSERT(isMainRunLoop()); ScrollingTree::scrollingTreeNodeDidScroll(node, scrollingLayerPositionAction); if (!m_scrollingCoordinatorProxy) return; std::optional<FloatPoint> layoutViewportOrigin; if (is<ScrollingTreeFrameScrollingNode>(node)) layoutViewportOrigin = downcast<ScrollingTreeFrameScrollingNode>(node).layoutViewport().location(); m_scrollingCoordinatorProxy->scrollingTreeNodeDidScroll(node.scrollingNodeID(), node.currentScrollPosition(), layoutViewportOrigin, scrollingLayerPositionAction); }

The crash occurs in this function. Check the commit record of this function:

To put it simply, the m_scrollingCoordinatorProxy object used in the scrollingTreeNodeDidScroll method is changed to a weak pointer and a null check is performed. This change is the solution to the problem that the m_scrollingCoordinatorProxy memory is still being accessed after it is released.

This commit was submitted on February 28, 2023, and the commit log is:

 [UI-side compositing] RemoteScrollingTree needs to hold a weak ref to the RemoteScrollingCoordinatorProxyhttps://bugs.webkit.org/show_bug.cgi?id=252963rdar://105949247 Reviewed by Tim Horton. The scrolling thread can extend the lifetime of the RemoteScrollingTree via activity on that thread,so RemoteScrollingTree needs to hold a nullable reference to the RemoteScrollingCoordinatorProxy;use a WeakPtr. [UI-side compositing] RemoteScrollingTree needs to hold a weak ref to the RemoteScrollingCoordinatorProxy https://bugs.webkit.org/show_bug.cgi?id=252963 rdar://105949247 Reviewed by Tim Horton. The scrolling thread can extend the lifetime of the RemoteScrollingTree via activity on that thread, so RemoteScrollingTree needs to hold a nullable reference to the RemoteScrollingCoordinatorProxy; use a WeakPtr.

At this point, we have basically confirmed that this crash stack is a bug in the internal implementation of webkit, and Apple's internal developers finally solved it using weak references.

At the same time, after the fix was launched, the crash rate of this crash was reduced to 0.

6. Summary

The crash in this article took nearly a year from its occurrence to its resolution. At first, it was judged based on the online log that the problem was caused by h5 page return & h5 page scrolling. Although the problem was almost solved after disabling gestures, there were still sporadic crash reports online. Therefore, in order to ensure the online stability of the h5 offline function, the problem needs to be solved perfectly.

The crash in this article seems familiar, but after verification and reading the source code, I found that it was not what I imagined. I continued to find the real scrollview proxy object in the crash stack by guessing + reading the source code, and then solved the problem on the app side. Finally, I found that it was a bug in Apple's webkit.

The crash problem in this article is essentially a wild pointer problem. So is there a universal solution to locate the wild pointer problem?