Crash in PDFView / PDFPageAnalyzerV2

Question

Created May ’26

Replies 4

Boosts 0

Views 1k

Participants 4

Hello. Some users of my app experience crashes that mention PDFKit. I managed to find out what specific PDF file caused the crash and created a sample that demonstrates the issue and created a bug report in Feedback Assistant (FB22409977). Unfortunately I didn't get any answer for over a month, hence I'm writing it here so others can see that this is a known issue.

The crash repro sample is very simple, it's just a PDFView that opens a bundled PDF file upon application lanunch. To cause the crash it is only needed to zoom-in and move around the page that has a table. The crash happens when the system tries to do some sort of OCR. The original crash report came from iPhone 11 user running iOS 26.3.1. Recently another user with iPhone 16 Pro Max running 26.5 experienced the same crash.

Thread 12 Queue : PDFKWit.PDFDocument.formFillingQueue (serial)
#0	0x000000018d320bd8 in PageLayout::GetBoundsForRangeWithinLine ()
#1	0x000000018d320c88 in PageLayout::GetBoundsForTextRange ()
#2	0x000000018d393028 in CGPDFTaggedNodeCreateCopyWithStringRange ()
#3	0x000000018d316630 in invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) ()
#4	0x000000018d104f00 in CGPDFPageEnumerateAnnotations ()
#5	0x000000018d106968 in CGPDFPageCopyRootTaggedNode ()
#6	0x000000018d106710 in CGPDFPageInsertTableDescriptions ()
#7	0x00000001957a65b8 in +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] ()
#8	0x00000001957a3030 in +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] ()
#9	0x000000019584c018 in __31-[PDFView visiblePagesChanged:]_block_invoke ()

When CG_PDF_VERBOSE env variable is set, "New text range needs to be within the original node's text range." warning is printed to console several times before the crash happens.

Answered by DTS Engineer in 888111022

Thank you for filing a bug report. Looking at your bug remains open and it has been assigned to an engineer for investigation. Please continue testing your software in new system software updates and beta releases as they become available. And please update the status of your bug whenever you do a new test. Please see https://developer.apple.com/download/ for the most recent beta releases.

Answer 1

DTS Engineer OP

Apple

May ’26

Accepted Answer

Recommended

Thank you for filing a bug report. Looking at your bug remains open and it has been assigned to an engineer for investigation. Please continue testing your software in new system software updates and beta releases as they become available. And please update the status of your bug whenever you do a new test. Please see https://developer.apple.com/download/ for the most recent beta releases.

Answer 2

TiagoColleoniZaro OP

May ’26

I have a similar issue:

Crashed: PDFKit.PDFDocument.formFillingQueue
0  CoreGraphics                   0x32dc3c PageLayout::GetBoundsForRangeWithinLine(CFRange, std::__1::optional<unsigned long>) const + 380
1  CoreGraphics                   0x32dcf0 PageLayout::GetBoundsForTextRange(CFRange) const + 176
2  CoreGraphics                   0x384ffc CGPDFTaggedNodeCreateCopyWithStringRange + 204
3  CoreGraphics                   0x322fc0 invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) + 476
4  CoreGraphics                   0x14b788 CGPDFPageEnumerateAnnotations + 152
5  CoreGraphics                   0x14d2a0 CGPDFPageCopyRootTaggedNode + 580
6  CoreGraphics                   0x14d028 CGPDFPageInsertTableDescriptions + 196
7  PDFKit                         0x6cfc +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] + 1752
8  PDFKit                         0x35b4 +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] + 1284
9  PDFKit                         0xb638c __31-[PDFView visiblePagesChanged:]_block_invoke + 64
10 libdispatch.dylib              0x19a8 _dispatch_call_block_and_release + 32
11 libdispatch.dylib              0x1b1e4 _dispatch_client_callout + 16
12 libdispatch.dylib              0x9fb0 _dispatch_lane_serial_drain + 740
13 libdispatch.dylib              0xaae4 _dispatch_lane_invoke + 448
14 libdispatch.dylib              0x14dac _dispatch_root_queue_drain_deferred_wlh + 284
15 libdispatch.dylib              0x146ac _dispatch_workloop_worker_thread + 720
16 libsystem_pthread.dylib        0x13b0 _pthread_wqthread + 292
17 libsystem_pthread.dylib        0x8c0 start_wqthread + 8

Answer 3

RenGate OP

Jun ’26

Looks like this issue has been resolved in iOS 27.0 beta. At least I can't reproduce it with my initial PDF samples.

Answer 4

ClassicalDude OP

17h

We have been chasing the same class from a different angle – not a crash inside it, but an unbounded leak. On iPadOS 26.6, every PDFDocument whose pages get rendered starts a VNRecognizeDocumentsRequest pipeline that is never released: roughly 2.7 OS threads and 20 MB per document, permanently. Our process reached 153 threads and 1.5 GB in under seven minutes of repeated document loads.

It is not released by replacing PDFView.document, by deallocating the PDFView, or by time – with the app fully idle the thread count keeps rising.

One thing that may save you time: usePageViewController(true, withViewOptions: nil) does not help with this. It reduces visiblePagesChanged: frequency, and in our measurements page changes on a stable document leak nothing at all – around 1000 of them left the footprint declining. The variable is newly rendered documents, not new pages.

PDFView does carry -setDocumentAnalysisEnabled: / -isDocumentAnalysisEnabled, none of it public. With analysis off, our leak goes to exactly zero over 28 document loads.

If you are facing the same issue, it would help if you also file feedback and suggest that these properties are made public. An analysis that never starts cannot crash – and in many cases the analysis is not relevant to the app.