Chrome for iOS is getting crash reports in ShareableBitmap::createGraphicsContext, mostly (> 50%) on twitter.com pages with large images. This is new in iOS 15.0, and is still occurring on iOS 15.2. Looking for recent changes in the call stack, I wonder if this is related to r281661. Here's the stack: CRASHED [EXC_BAD_ACCESS / KERN_INVALID_ADDRESS @ 0x00000018 ] 0x00000001923179a8 (WebKit + 0x003569a8) WebKit::wantsExtendedRange(WebKit::ShareableBitmap::Configuration const&) 0x0000000192317a08 (WebKit + 0x00356a08) WebKit::ShareableBitmap::createGraphicsContext() 0x0000000192317a08 (WebKit + 0x00356a08) WebKit::ShareableBitmap::createGraphicsContext() 0x0000000192317b58 (WebKit + 0x00356b58) WebKit::ShareableBitmap::makeCGImageCopy() 0x00000001923ad30c (WebKit + 0x003ec30c) WebKit::PageClientImpl::startDrag(WebCore::DragItem const&, WebKit::ShareableBitmap::Handle const&) 0x000000019274aba0 (WebKit + 0x00789ba0) WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 0x00000001920192cc (WebKit + 0x000582cc) IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 0x0000000192421a68 (WebKit + 0x00460a68) WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 0x0000000191ff700c (WebKit + 0x0003600c) IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) 0x0000000191ff661c (WebKit + 0x0003561c) IPC::Connection::dispatchIncomingMessages() 0x000000018f914778 (JavaScriptCore + 0x01133778) WTF::RunLoop::performWork() 0x000000018f9158e8 (JavaScriptCore + 0x011348e8) WTF::RunLoop::performWork(void*) 0x000000018395102c (CoreFoundation + 0x000bb02c) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x0000000183961cec (CoreFoundation + 0x000cbcec) __CFRunLoopDoSource0 0x000000018389bff4 (CoreFoundation + 0x00005ff4) __CFRunLoopDoSources0 0x00000001838a1800 (CoreFoundation + 0x0000b800) __CFRunLoopRun 0x00000001838b53c4 (CoreFoundation + 0x0001f3c4) CFRunLoopRunSpecific 0x000000019f0c6388 (GraphicsServices + 0x00001388) GSEventRunModal 0x000000018625b05c (UIKitCore + 0x0051b05c) -[UIApplication _run] 0x0000000185fd8b88 (UIKitCore + 0x00298b88) UIApplicationMain
Thanks for the report, Ali. There were a few changes to ShareableBitmap in the iOS 15 release. I'll try to reproduce.
<rdar://problem/85478309>
It's possible ShareableBitmap::create returned null due to either numBytes overflowing (though that would require something like a 32k x 32k image) or the ShareableBitmapMalloc::tryMalloc call failing. Either way, PageClientImpl::startDrag should probably defend against ShareableBitmap::create returning null.
(In reply to Cameron McCormack (:heycam) from comment #3) > It's possible ShareableBitmap::create returned null due to either numBytes > overflowing (though that would require something like a 32k x 32k image) or > the ShareableBitmapMalloc::tryMalloc call failing. Either way, > PageClientImpl::startDrag should probably defend against > ShareableBitmap::create returning null. Thanks for having a look. A large fraction of the crash reports are happening when free memory is low, so it's probably the ShareableBitmapMalloc::tryMalloc call failing.
(In reply to Ali Juma from comment #4) > Thanks for having a look. A large fraction of the crash reports are > happening when free memory is low, so it's probably the > ShareableBitmapMalloc::tryMalloc call failing. Oh actually this is the ShareableBitmap::create call that takes a shared memory handle, so there's no allocation failure here. But there are still paths where we can return null (mapping the shared memory failing, or numBytes is too big, or the shared memory size not matching the number of bytes we expect).
Created attachment 444579 [details] Patch
Committed r285976 (244373@main): <https://commits.webkit.org/244373@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 444579 [details].