iOS26.x后PDFKit + PKCanvasView组合下的滑动放大极易崩溃

最常见的是这个: Thread 1 Queue : com.apple.main-thread (serial) #0 0x0000000190bcb3c4 in CFRelease.cold.2 () #1 0x0000000190a2c50c in CFRelease () #2 0x00000001d194ad38 in -[PDFTileSurface releaseSurface] () #3 0x00000001d194c230 in -[PDFTilePool releasePDFTileSurface:] () #4 0x00000001d194f618 in -[PDFPageLayerTile dealloc] () #5 0x0000000190a4778c in -[__NSArrayI_Transfer dealloc] () #6 0x000000018d5d57f8 in AutoreleasePoolPage::releaseUntil () #7 0x000000018d5d5684 in objc_autoreleasePoolPop () #8 0x000000019668d43c in -[UIScrollView setContentOffset:] () #9 0x000000018dd70918 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] () #10 0x000000018ddd1298 in -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey🔑 key:usingBlock:] () #11 0x000000018ded5b28 in _NSSetPointValueAndNotify () #12 0x0000000196c49af0 in -[UIScrollView _smoothScrollSyncWithUpdateTime:] () #13 0x0000000196c491a0 in -[UIScrollView _smoothScrollWithUpdateTime:] () #14 0x0000000196c490b0 in -[UIScrollView smoothScrollDisplayLink:] () #15 0x000000026186a66c in -[DYDisplayLinkInterposer forwardDisplayLinkCallback:] () #16 0x00000001914cc77c in CA::Display::DisplayLinkItem::dispatch () #17 0x00000001914a4388 in CA::Display::DisplayLink::dispatch_items () #18 0x00000001914bb2b8 in CA::Display::DisplayLink::dispatch_deferred_display_links () #19 0x000000019671e2a8 in _UIUpdateSequenceRunNext () #20 0x000000019671b834 in schedulerStepScheduledMainSectionContinue () #21 0x00000002a437256c in UC::DriverCore::continueProcessing () #22 0x0000000190a3f1d8 in __CFMachPortPerform () #23 0x0000000190a81824 in CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION () #24 0x0000000190a8174c in __CFRunLoopDoSource1 () #25 0x0000000190a4c6e4 in __CFRunLoopRun () #26 0x0000000190a4b54c in _CFRunLoopRunSpecificWithOptions () #27 0x0000000235da7498 in GSEventRunModal () #28 0x0000000196744244 in -[UIApplication _run] () #29 0x00000001966af158 in UIApplicationMain () #30 0x00000001968bb618 in ___lldb_unnamed_symbol_1893835b0 () #31 0x0000000105a7a308 in static UIApplicationDelegate.main() () #32 0x0000000105a7a278 in static AppDelegate.$main() () #33 0x0000000105a7a3cc in main () #34 0x000000018d659c1c in start ()

Answered by DTS Engineer in 896871022

Thanks for the report, and for including the crash log.

I built a test on iOS 26 with the same combination: a PDFView with an overlaid PKCanvasView. I then stress-tested it on an iPad. It zoomed repeatedly to about 9x and back while running animated smooth scrolls. I also pinch-zoomed deep into a page and flick-scrolled quickly. I could not reproduce the crash using Apple frameworks alone.

Here is how I read your stack. The crash is an over-release. During a display-link-driven smooth scroll, setting the content offset drains an autorelease pool. That deallocates PDFKit tiles, and CFRelease then hits its error path (CFRelease.cold.2) while releasing a tile surface. That signature means an object is released one time too many.

One frame in the stack is not part of PDFKit, UIKit, or CoreAnimation: -[DYDisplayLinkInterposer forwardDisplayLinkCallback:]. This is code in your app, so you will know what it is. It intercepts and forwards the CADisplayLink callback that drives the smooth scroll where the crash occurs. It sits directly in the failing path and affects scroll timing. So a useful next step is to find out whether the crash still occurs without it.

Here is a way to isolate it:

  • Reproduce with DYDisplayLinkInterposer disabled or removed, so the display-link callback runs without it. If the crash stops, that isolates it to DYDisplayLinkInterposer. If it still crashes without it, that points at PDFKit.
  • If it still reproduces with only Apple frameworks, please file a report with Feedback Assistant. A small sample project that crashes with just PDFKit and PencilKit is the key piece. Include a sysdiagnose captured right after the crash and the symbolicated crash report, so the team can investigate directly.
  • It would also help to know how your PDFView and PKCanvasView are composited, in particular whether the canvas tracks the PDF's zoom and scroll. That matters in case the integration is involved.

Since heavy zoom and scrolling did not reproduce it here with PDFKit and PencilKit by themselves, isolating DYDisplayLinkInterposer is where I would start.

Please let me know what you find.

Thanks for the report, and for including the crash log.

I built a test on iOS 26 with the same combination: a PDFView with an overlaid PKCanvasView. I then stress-tested it on an iPad. It zoomed repeatedly to about 9x and back while running animated smooth scrolls. I also pinch-zoomed deep into a page and flick-scrolled quickly. I could not reproduce the crash using Apple frameworks alone.

Here is how I read your stack. The crash is an over-release. During a display-link-driven smooth scroll, setting the content offset drains an autorelease pool. That deallocates PDFKit tiles, and CFRelease then hits its error path (CFRelease.cold.2) while releasing a tile surface. That signature means an object is released one time too many.

One frame in the stack is not part of PDFKit, UIKit, or CoreAnimation: -[DYDisplayLinkInterposer forwardDisplayLinkCallback:]. This is code in your app, so you will know what it is. It intercepts and forwards the CADisplayLink callback that drives the smooth scroll where the crash occurs. It sits directly in the failing path and affects scroll timing. So a useful next step is to find out whether the crash still occurs without it.

Here is a way to isolate it:

  • Reproduce with DYDisplayLinkInterposer disabled or removed, so the display-link callback runs without it. If the crash stops, that isolates it to DYDisplayLinkInterposer. If it still crashes without it, that points at PDFKit.
  • If it still reproduces with only Apple frameworks, please file a report with Feedback Assistant. A small sample project that crashes with just PDFKit and PencilKit is the key piece. Include a sysdiagnose captured right after the crash and the symbolicated crash report, so the team can investigate directly.
  • It would also help to know how your PDFView and PKCanvasView are composited, in particular whether the canvas tracks the PDF's zoom and scroll. That matters in case the integration is involved.

Since heavy zoom and scrolling did not reproduce it here with PDFKit and PencilKit by themselves, isolating DYDisplayLinkInterposer is where I would start.

Please let me know what you find.

非常感谢你的回复

关于你提到的DYDisplayLinkInterposer,我确认不是我应用程序的代码。我在github上找到了它属于 PrivateFrameworks/GPUToolsCore.framework/DYDisplayLinkInterposer.h,这属于iOS-x-Runtime-Headers 提供的示例,这也是Apple 的代码 因此我无法分类,去使用你提供的方案尝试

其次,我可以提供更多细节给您 1、版本号上 26.4.2 (23E261), 26.5 (23F77) 最为高频 2、 PDFView 和 PKCanvasView 是如何组合的 我们使用PDFPageOverlayViewProvider(iOS 16+)将自定义视图叠加到每个PDF页面上。MEPDFEditView包含一个PKCanvasView以及其他几个子视图(形状图层、磁带视图、属性编辑器)。叠加视图在pdfView(_:overlayViewFor:)中创建,其生命周期由PDFKit管理——每个可见页面都有自己的叠加视图,由PDFKit自动缩放/定位。没有手动框架同步;PKCanvasView位于正确的PDF页面坐标的疊加中。 已经做的尝试有,只有pdfkit,无叠加视图,滑动流畅不崩溃 只有pdfkit,叠加视图是有PKCanvasView 滑动加载数据,会崩溃 低设备型号,如ipad8 ipad9很容易出现,一个500多页500M的笔记,基本上竖向滑动不到完整 当然我的页面上会有不少PKDrawing

我的疑问是,为什么同为ipad9 ipad0S18.x的设备就不会频繁触发 iOS26.x就会如此频繁,有哪些行为是上层应用可以做到的

We're seeing a smattering of crashes with PDF Views as well, some that looks similar the original one in this thread.

Crashes in the PDFView clients started appearing in 26.3 and have maintained across subsequent versions. We certainly did not see these errors in 26.0 or in the pre-26 OS versions.

The crashes are heavily slanted towards iPads.

We have not had any luck reproducing this crash on our own

Thanks to both of you for the added detail on your setup, and for the two crash logs. Together they change where the evidence points, so let me update my read.

You can set aside the isolation step from my last reply. One of the crash logs shared here reaches the same over-release on the main queue, with no app code in the failing path, directly from PDFKit's tile machinery:

CFRelease.cold.2  <-  CFRelease
-[PDFTileSurface releaseSurface]
-[PDFTilePool releasePDFTileSurface:]
-[PDFPageLayerTile dealloc]
-[PDFPageLayer tileDrawingComplete:]

That is the same over-release as your original stack, reached by a different route (tile-draw completion rather than a scroll). So this is not your PDFPageOverlayViewProvider and PKCanvasView wiring. The over-release is inside PDFKit's tile pool, and it reproduces with no PencilKit in the path. A PencilKit overlay looks like an aggravator rather than a requirement.

The two logs are in fact two different crashes, worth separating:

  • The tile over-release above (CFRelease.cold.2 in -[PDFTileSurface releaseSurface]). A tile surface is released one time too many.
  • The second log crashes elsewhere: an out-of-memory abort (std::bad_alloc) inside Vision text recognition (CRDetectorPostProcessV3). It runs from PDFKit's automatic per-page analysis (+[PDFPageAnalyzerV2 analyzePage:...] into VNRecognizeDocumentsRequest) as visible pages change during scrolling.

Both occur during the same activity. As pages become visible, PDFKit runs document analysis (the Vision text-recognition path) on them while the tile pool renders and releases tiles. On a very large document, such as your 500-page, 500 MB notebook, on a 3 GB iPad, that path is memory-intensive. That is consistent with why the 8th and 9th generation iPads see it most, and why one of the logs is an allocation failure.

On iOS 18 versus 26: the 26.x stacks show this automatic per-page analysis running during scrolling, which is the machinery being exercised when the crash occurs. I can describe what the stacks show, but I cannot speak to why the behavior differs across versions.

You asked what the app itself can do. I looked, and there is no public API to turn off that automatic page analysis. So I do not have a reliable app-side fix to offer: the over-release is inside PDFKit, not in your code.

The over-release appears here in both the original stack and one of the shared crash logs, and neither is reported before iOS 26. This is worth reporting through Feedback Assistant. Two separate reports would help:

  • One for the PDFTileSurface over-release, with a symbolicated crash log and, if you can, a small project that reproduces with PDFView alone.
  • One for the Vision text-recognition crash during page analysis, with its symbolicated crash log.

For each, please include a sysdiagnose captured right after the crash, and the device and iOS versions where it occurs. A symbolicated crash log is the key piece, particularly for the text-recognition one.

Please post the Feedback IDs here as well, so they can be referenced.

Please continue to test your software on the release and pre-release versions of system software available through your developer.apple.com account. Update your bug reports whenever you do. For beta pre-release versions, see https://developer.apple.com/download/.

For reference:

https://feedbackassistant.apple.com/feedback/23910345 我提供了一个pdf,这个pdf在ios26.5的ipad9设备上,预览中滑动即会闪退,希望对你有所帮助,期待你更早回复什么版本会修复

iOS26.x后PDFKit + PKCanvasView组合下的滑动放大极易崩溃
 
 
Q