Crash Report – TRN_UndoManagerDestroy (PDFTron

Technical Support
, , ,
1

Product:
PDFTron - iOS Librabry (SPM)

Product Version:
11.3.85075

Hi PDFTron Team,

I recently encountered a crash while using the PDFTron library in an iOS application. The crash happens when the PDF starts loading:

open class PDFDocumentController: PTDocumentController {
    private var didCacheDocumentAtURL: GenericCompletion<URL>?

    public override init() {
        super.init()
    }

    required public init(coder: NSCoder) {
        super.init(coder: coder)
    }

    open override func shouldDeleteCachedDocument(at cachedDocumentURL: URL) -> Bool {
        didCacheDocumentAtURL?(.success(cachedDocumentURL))
        return super.shouldDeleteCachedDocument(at: cachedDocumentURL)
    }

    public func showAnnotations(_ annotationsXFDF: [String]) {
        annotationsXFDF.forEach {
            let fdfDoc = PTFDFDoc.create(fromXFDF: $0)
            document?.fdfMerge(fdfDoc)
        }
        pdfViewCtrl.update()
    }

    private func loadDocument(url: URL,
                              authToken: String,
                              onDidCacheDocumentAtURL: GenericCompletion<URL>? = nil) {
        didCacheDocumentAtURL = onDidCacheDocumentAtURL
        additionalHTTPHeaders = ["Authorization": "Bearer \(authToken)"]
        let options = PTDocumentOptions()
        options.sourcePathExtension = "pdf"
        openDocument(with: url, options: options)
    }

    public func loadDocument(diskURL: URL?,
                             remoteURL: URL,
                             authToken: String,
                             onDidCacheDocumentAtURL: GenericCompletion<URL>? = nil) {
        if let diskURL {
            loadDocument(url: diskURL, authToken: authToken)
        } else {
            loadDocument(url: remoteURL, authToken: authToken, onDidCacheDocumentAtURL: onDidCacheDocumentAtURL)
        }
    }
}

The crash occurred with the following stack trace:

Stack trace:

(lldb) bt  
* thread #962, stop reason = signal SIGABRT  
  * frame #0: 0x00000001e78702ec libsystem_kernel.dylib`__pthread_kill + 8  
    frame #1: 0x00000001fb64cc0c libsystem_pthread.dylib`pthread_kill + 268  
    frame #2: 0x00000001a6bcfba0 libsystem_c.dylib`abort + 180  
    frame #3: 0x00000001fb569ca4 libc++abi.dylib`abort_message + 132  
    frame #4: 0x00000001fb559e5c libc++abi.dylib`demangling_terminate_handler() + 348  
    frame #5: 0x0000000196b8b14c libobjc.A.dylib`_objc_terminate() + 144  
    frame #6: 0x00000001fb569068 libc++abi.dylib`std::__terminate(void (*)()) + 16  
    frame #7: 0x00000001fb56c35c libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88  
    frame #8: 0x00000001fb56c2a0 libc++abi.dylib`__cxa_throw + 308  
    frame #9: 0x0000000196b6f420 libobjc.A.dylib`objc_exception_throw + 420  
    frame #10: 0x000000019dad49bc Foundation`NSAllocateMemoryPages + 184  
    frame #11: 0x000000019dad1b80 Foundation`-[_NSPlaceholderData initWithBytes:length:copy:deallocator:] + 132  
    frame #12: 0x000000019dad18e8 Foundation`+[NSData(NSData) dataWithBytes:length:] + 40  
    frame #13: 0x0000000103e073dc PDFNet`___lldb_unnamed_symbol11713 + 144  
    frame #14: 0x000000010419d948 PDFNet`___lldb_unnamed_symbol21818 + 100  
    frame #15: 0x000000010419c860 PDFNet`___lldb_unnamed_symbol21808 + 244  
    frame #16: 0x000000010419a8c0 PDFNet`___lldb_unnamed_symbol21784 + 112  
    frame #17: 0x000000010423c50c PDFNet`___lldb_unnamed_symbol23812 + 492  
    frame #18: 0x000000010423b3cc PDFNet`___lldb_unnamed_symbol23799 + 656  
    frame #19: 0x0000000104497048 PDFNet`___lldb_unnamed_symbol34621 + 140  
    frame #20: 0x00000001fb64b06c libsystem_pthread.dylib`_pthread_start + 136

The other error was also reported in Sentry with the identifier: TRN_UndoManagerDestroy. Not sure if it’s connected, but also has to be fixed. (Please see attached image):

pdftron
pdftron1874×1200 304 KB

Could you please provide insight into what might be causing this issue or suggest any possible workarounds? Let me know if you need any additional information.

Best regards

1 Like
2

Thank you for reaching out to us through our Forum. In order to further assist you, we will need you to reproduce this issue and provide a video and sample of the issue you are encountering. You can submit a support ticket with all necessary materials here: Submit a ticket : Apryse

1 Like
3

Hello, could an update be posted as to what was the outcome here, its not easy to reproduce this issue as there is no clear indicator as to its cause, we have ~300 users experiencing this issue ~4,000 times in a 90 day period

1 Like
4

Thank you for your response. If you could create a ticket and submit it here: Submit a ticket : Apryse
Be sure to include reproduction steps, a sample project that can reproduce the issue, and a video demonstrating the issue you are experiencing. This would be best handled as a support ticket as it requires thorough investigation. I look forward to your response.

1 Like
5

We are encountering the exact same crash， any updates？

1 Like
6

Thank you for reaching out through our Forum. At this time, in order for us to further investigate this issue, we would require more information. You can submit a support ticket here: Submit a ticket : Apryse
and I’ll be able to follow up accordingly. Thank you for your cooperation.

1 Like
7

Thank you for the boilerplate response, but let’s be realistic here.

The necessary source code and crash logs are already laid out perfectly in this thread. Saying you “require more information” is factually incorrect and comes across as pure professional laziness to avoid digging into the code.

We pay for Apryse/PDFTron as a premium enterprise solution, not to play ticketing ping-pong. I am experiencing the exact same production block as the OP.

Instead of making your users do your administrative work, please copy-paste the data already provided here, forward it to your dev team, and give us a real, technical answer. What is the status of this crash?

1 Like
8

My sincerest apologies that you feel this is an inadequate response, however, it is known among our Engineering Team that the error message that arises from the UndoManagerDestroy is multifaceted in nature, and requires individual assistance for each case, as it can be any number of things, and does not pinpoint to an immediate issue. If you were to submit a Support Ticket, the investigation into the issue would be streamlined for your specific use-case. If you are looking for a solution and investigation into your project as to why this is happening, this would be the most adequate and investigative format for resolution. I look forward to your response and to further assisting you. Thank you for your understanding.

1 Like
9

Following up on my previous post, I want to share a highly disappointing update regarding Apryse’s support.

I raised a formal Support Ticket (#96758) providing complete crash logs. Instead of actually investigating, the support team simply asked for a static “sample project” and then quietly let the ticket auto-close.

Let’s address the technical reality of this crash so other developers using this SDK are aware:

  1. It is an asynchronous streaming race condition: The crash occurs intermittently inside TRN_UndoManagerDestroy, specifically when using PTPDFViewCtrl.OpenUrlAsync under poor network conditions.

  2. A static sample project cannot reproduce this: Because this is a multi-threaded destruction issue tied to network latency (when a user exits the viewer while the PDF stream is still active/interrupted), a 10-line local demo will not replicate the race condition.

  3. The bug lies in the SDK’s internal lifecycle: We have already explicitly called pdfViewCtrl.undoManager?.disableUndoRegistration() during initialization, yet the crash inside TRN_UndoManagerDestroy still persists. This strongly indicates that when the streaming view controller is being torn down, the SDK attempts to access or double-free a null/dangling pointer inside the closed-source C++ core.

Asking a paying customer to do your QA department’s job by providing a 100% reproducible demo for an intermittent, network-dependent multi-threading bug is completely unreasonable.

We do not have access to your proprietary C++ source code. But your Engineering Team does. They have our crash logs, the symbols, and the code paths for TRN_UndoManagerDestroy.

I urge the Apryse team to reopen Ticket #96758 and escalate this to an L2/L3 Mobile SDK Engineer who actually understands the memory management and asynchronous lifecycle of PTPDFViewCtrl.

We deserve a real technical analysis, not another automated ticket closure.

1 Like