Bug 250062 – REGRESSION (iOS 16): The renderer process is frozen when opening a specific PDF via mozilla/pdfjs

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

[Seokho Song]

Created attachment 464319 [details]
pdf file including otf font or a lot of images

Since ios 16, pdfjs freeze the render process when it opens a specific type of PDF file. (I'm not sure, OTF fonts, or a lot images?)

The process freezing makes it unable to interact with any dom element and refresh the page and use the inspector.

FYI: https://github.com/mozilla/pdf.js/issues/15881

(Maybe it is related to Canvas?)

Versions: 
iOS 16.2 (maybe ios 16.1 or 16.0)
Make sure the 'release' build of Webkit.

Reproduction steps:
open safari on iOS simulator or the device
open https://mozilla.github.io/pdf.js/web/viewer.html
open the attached file

What is the expected result?
The renderer process does not freeze.

What happens instead?
The renderer process is frozen.

Additional information:
I tested it by locally built Webkit from a recent version from the main branch (ef906728e98c7ea5144f72c4a5bec2a2561c1e8d) on the local computer. 
Built with the debug mode (`build-webkit --debug  --ios-simulator`), It worked properly.
On the other hand, the release mode(`build-webkit --ios-simulator`) made freezing.


Here is a backtrace from lldb that attached the renderer process that is frozen:

 thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff8361191fe libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007ff8361767e1 libsystem_pthread.dylib`_pthread_cond_wait + 1243
    frame #2: 0x00000005686047ef JavaScriptCore`WTF::ThreadCondition::timedWait(WTF::Mutex&, WTF::WallTime) [inlined] WTF::ThreadCondition::wait(this=0x00000005670a4d10, mutex=0x00000005670a4cd0) at ThreadingPOSIX.cpp:603:18 [opt]
    frame #3: 0x00000005686047e4 JavaScriptCore`WTF::ThreadCondition::timedWait(this=0x00000005670a4d10, mutex=0x00000005670a4cd0, absoluteTime=<unavailable>) at ThreadingPOSIX.cpp:613:9 [opt]
    frame #4: 0x00000005685df177 JavaScriptCore`WTF::ParkingLot::parkConditionallyImpl(address=0x0000600002dec6c2, validation=0x00007ff7b630abd8, beforeSleep=0x00007ff7b630abc0, timeout=0x00007ff7b630ac90)> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.cpp:595:34 [opt]
    frame #5: 0x00000005685a3b9a JavaScriptCore`bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&) [inlined] WTF::ParkingLot::ParkResult WTF::ParkingLot::parkConditionally<bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda'(), bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda0'()>(address=0x0000600002dec6c2, validation=0x00007ff7b630abf0, beforeSleep=0x00007ff7b630abf8, timeout=0x00007ff7b630ac90)::'lambda0'() const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.h:82:16 [opt]
    frame #6: 0x00000005685a3b5a JavaScriptCore`bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(this=0x0000600002dec6c2, lock=0x0000600002dec6c1, timeout=0x00007ff7b630ac90) at Condition.h:192:22 [opt]
    frame #7: 0x00000005685a8365 JavaScriptCore`WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&) [inlined] WTF::Condition::waitUntil(this=0x0000600002dec6c2, lock=0x0000600002dec6c1, timeout=0x00007ff7b630ac90) at Condition.h:77:16 [opt]
    frame #8: 0x00000005685a8357 JavaScriptCore`WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&) [inlined] bool WTF::Condition::waitUntilUnchecked<WTF::Lock, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(this=0x0000600002dec6c2, lock=0x0000600002dec6c1, timeout=0x00007ff7b630ac90, predicate=<unavailable>)::$_0 const&) at Condition.h:213:18 [opt]
    frame #9: 0x00000005685a8345 JavaScriptCore`WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&) [inlined] bool WTF::Condition::waitUntil<WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(this=0x0000600002dec6c2, lock=0x0000600002dec6c1, timeout=0x00007ff7b630ac90, predicate=<unavailable>)::$_0 const&) at Condition.h:91:16 [opt]
    frame #10: 0x00000005685a8345 JavaScriptCore`WTF::BinarySemaphore::waitUntil(this=0x0000600002dec6c0, absoluteTime=0x00007ff7b630ac90) at BinarySemaphore.cpp:41:34 [opt]
    frame #11: 0x00000005633a5bb5 WebKit`IPC::Connection::waitForSyncReply(WTF::ObjectIdentifier<IPC::Connection::SyncRequestIDType>, IPC::MessageName, IPC::Timeout, WTF::OptionSet<IPC::SendSyncOption>) [inlined] IPC::Connection::SyncMessageState::wait(this=<unavailable>, timeout=Timeout @ 0x00007ff7b630ac68) at Connection.cpp:91:44 [opt]
    frame #12: 0x00000005633a5ba1 WebKit`IPC::Connection::waitForSyncReply(this=0x0000000567111400, syncRequestID=(m_identifier = 10553), messageName=RemoteRenderingBackend_PrepareBuffersForDisplay, timeout=Timeout @ 0x00007ff7b630ac68, sendSyncOptions=(m_storage = 0)) at Connection.cpp:792:34 [opt]
    frame #13: 0x00000005633a521a WebKit`IPC::Connection::sendSyncMessage(this=0x0000000567111400, syncRequestID=(m_identifier = 10553), encoder=<unavailable>, timeout=<unavailable>, sendSyncOptions=<unavailable>) at Connection.cpp:742:38 [opt]
    frame #14: 0x000000056309445f WebKit`IPC::Connection::SendSyncResult<Messages::RemoteRenderingBackend::PrepareBuffersForDisplay> IPC::Connection::sendSync<Messages::RemoteRenderingBackend::PrepareBuffersForDisplay>(this=0x0000000567111400, message=<unavailable>, destinationID=<unavailable>, timeout=Timeout @ 0x00007ff7b630ad50, sendSyncOptions=(m_storage = 0)) at Connection.h:627:45 [opt]
    frame #15: 0x00000005630943dd WebKit`IPC::Connection::SendSyncResult<Messages::RemoteRenderingBackend::PrepareBuffersForDisplay> IPC::StreamClientConnection::sendSync<Messages::RemoteRenderingBackend::PrepareBuffersForDisplay, WebKit::RenderingBackendIdentifierType>(this=0x0000000567158c00, message=<unavailable>, destinationID=<unavailable>, timeout=Timeout @ 0x00007ff7b630adc0) at StreamClientConnection.h:251:26 [opt]
    frame #16: 0x000000056308e98a WebKit`WebKit::RemoteRenderingBackendProxy::prepareBuffersForDisplay(WTF::Vector<WebKit::RemoteRenderingBackendProxy::LayerPrepareBuffersData, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) [inlined] auto WebKit::RemoteRenderingBackendProxy::sendSync<Messages::RemoteRenderingBackend::PrepareBuffersForDisplay>(this=0x00006000030bcfc0, message=0x00007ff7b630ae50, timeout=Timeout @ 0x0000600001afa980) at RemoteRenderingBackendProxy.h:171:35 [opt]
    frame #17: 0x000000056308e961 WebKit`WebKit::RemoteRenderingBackendProxy::prepareBuffersForDisplay(this=0x00006000030bcfc0, prepareBuffersInput=<unavailable>) at RemoteRenderingBackendProxy.cpp:317:23 [opt]
    frame #18: 0x0000000562c2cdcc WebKit`WebKit::RemoteLayerWithRemoteRenderingBackingStoreCollection::prepareBackingStoresForDisplay(this=<unavailable>, transaction=0x00007ff7b630b0c0) at RemoteLayerWithRemoteRenderingBackingStoreCollection.mm:102:46 [opt]
    frame #19: 0x0000000562f1a498 WebKit`WebKit::RemoteLayerTreeContext::buildTransaction(this=0x00000005670a0600, transaction=0x00007ff7b630b0c0, rootLayer=0x000000056713cc60) at RemoteLayerTreeContext.mm:157:31 [opt]
    frame #20: 0x0000000562b639f7 WebKit`WebKit::RemoteLayerTreeDrawingArea::updateRendering(this=0x0000000567140800) at RemoteLayerTreeDrawingArea.mm:333:31 [opt]
    frame #21: 0x0000000571779834 WebCore`WebCore::ThreadTimers::sharedTimerFiredInternal(this=0x000000056701c450) at ThreadTimers.cpp:127:23 [opt]
    frame #22: 0x00000005717ad0ff WebCore`WebCore::timerFired((null)=<unavailable>, (null)=<unavailable>) at MainThreadSharedTimerCF.cpp:85:40 [opt]
    frame #23: 0x00007ff8003887c9 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
    frame #24: 0x00007ff800388313 CoreFoundation`__CFRunLoopDoTimer + 812
    frame #25: 0x00007ff800387a8a CoreFoundation`__CFRunLoopDoTimers + 243
    frame #26: 0x00007ff8003822d2 CoreFoundation`__CFRunLoopRun + 2126
    frame #27: 0x00007ff8003816a7 CoreFoundation`CFRunLoopRunSpecific + 560
    frame #28: 0x00007ff800c568b4 Foundation`-[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 213
    frame #29: 0x00007ff800c56ad2 Foundation`-[NSRunLoop(NSRunLoop) run] + 76
    frame #30: 0x00007ff80008ca07 libxpc.dylib`_xpc_objc_main + 440
    frame #31: 0x00007ff80008e865 libxpc.dylib`xpc_main + 122
    frame #32: 0x0000000562c25d4d WebKit`WebKit::XPCServiceMain((null)=<unavailable>, (null)=<unavailable>) at XPCServiceMain.mm:207:5 [opt]
    frame #33: 0x00000005601aa2bf dyld_sim`start_sim + 10
    frame #34: 0x00000001199e2310 dyld`start + 2432

[Simon Fraser (smfr)]

Looks like a GPU Process hang.

[Radar WebKit Bug Importer]

<rdar://problem/103879811>

[Eknoor]

Hi Seokho, is there a user facing symptom we can look for when the issue reproduces? A screen recording of your steps to reproduce would be greatly appreciated. Thank you.

[Seokho Song]

Created attachment 464338 [details]
on iPhone 12 pro, device recording

1. Open https://mozilla.github.io/pdf.js/web/viewer.html on Safari
2. Open one of the pdf files unzipped reroduction_cases.zip
3. Reproduction!

[Seokho Song]

Created attachment 464339 [details]
Safari release mode build

1. Run ./Tools/Scripts/run-safari --ios-simulator
2. Open https://mozilla.github.io/pdf.js/web/viewer.html on safari in simulator 
3. Open one of the pdf files unzipped reroduction_cases.zip
4. Reproduction!

[Seokho Song]

Created attachment 464340 [details]
Safari debug mode build

!!!No freezing case!!!

1. Run ./Tools/Scripts/run-safari --ios-simulator --debug
2. Open https://mozilla.github.io/pdf.js/web/viewer.html on safari in simulator 
3. Open one of the pdf files unzipped reroduction_cases.zip
4. **No Reproduction**

[Seokho Song]

Sure :)
The user of our company(using mozilla/pdfjs) complain to CS that the browser is frozen. (Quite a bit frequently)

Here are 2 attachments to reproduce and debug mode screen recording that does not reproduce the case.

(build commit hash is ef906728e98c7ea5144f72c4a5bec2a2561c1e8d)

Could the resolved version of safari be a hotfix or a minor patch for iOS?

If you need further information, please feel free to request it.

Thanks.

[Seokho Song]

Hi folks, I'd like to track this issue in our company.
What is the current status of this issue?
Any estimated time for when to fix it?

[Seokho Song]

Friendly ping for this issue :)

Can I ask to increase the importance level to P1/Critical?

Due to the customer of our company keep claiming about iOS browser (Webkit) freezing.

Also, the GitHub issue related to process freezing keeps opened like 
https://github.com/mozilla/pdf.js/issues/15919

[Kimmo Kinnunen]

Thanks for the report!
This was fixed as part of bug 250318.
This was related to Web process -> GPU Process communication:

- PDFJS creates a lot of canvas commands -> command buffer wraps around often
- Stream command buffer thinks 10 is the minimum bytes needed for the critical command
- Stream command buffer thinks SetStreamDestinationID is the critical command
- If the command buffer is within 10-15 bytes from wrap around during SetStreamDestinationID, this may fail because sometimes SetStreamDestinationID takes 16 bytes due to alignment within the command
- If SetStreamDestinationID, the command fails. The RRB is such a client that it doesn’t check for send failures
- If the failed command is a object creation command (create image buffer), the server doesn’t know about it
- Sender sends a new command to the new object (that did not get created)
- Down the line, the server sees a message to an object that has not been created. It doesn’t know what message it is, and as such it cannot parse the message. It must timeout the message and all subsequent messages
- The sender sends a sync message, in this case prepareBuffersForDisplay. 
- The sender times out waiting for the message

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