![]() ![]() Unfortunately, the surrounding pseudocode Hopper produced wasn’t helpful: It involved too many incomprehensible instructions that were hard to reason about. I landed at a line that raises an exception with the exact message we were seeing: The disassembly process takes time.Īfter Hopper was done disassembling, I searched for the _validatedViewControllers… symbol in the Procedures tab, selected Navigate → Go To Offset in Procedure, and entered 516 - the value from the crash report. So I went with the latter and left my desk to make myself a cup of coffee. That’s because, beginning with iOS 12, Apple started using UIKit as a wrapper around UIKitCore, where all the implementation now lives. Instead, they’re all packed into a shared DYLD cache at /System /Library /Caches / /dyld_shared_cache_arm64e.įortunately, Hopper, my disassembler of choice, has supported disassembling DYLD caches for quite some time! I opened it and was presented with the choice of a concrete framework to disassemble.Ĭhoosing UIKit would lead me nowhere. On iOS, framework binaries can’t be found at their classic /System /Library /PrivateFrameworks location. I downloaded it, unzipped it, and mounted the largest DMG I found inside, having correctly assumed that it must contain the file system. I went to the IPSW Downloads website and found the specific firmware archive I needed. To find out what exact condition was causing the exception to be raised, I needed to disassemble UIKit - and not just any UIKit - the exact UIKit binary from iOS 14.4 compiled for iPad11,6. But what about the offset? Hopping into Hopper ![]() Without access to UIKit’s source files, the file name and line number are meaningless. The above means that the exception was raised in the UIPageViewController class, in the _validatedViewControllers… method, and at offset 516, which corresponds to line 1224 in UIPageViewController.m. I chose one of them and found three clues inside: the device hardware model (iPad11,6), the iOS version (14.4), and where the exception was raised: So next, I logged into our crash reporting service to collect the symbolicated. Swiping left from near the center of the screen to go to the next pageĮven when repeating the above steps, the chance of stumbling upon the crash was still very low: It took multiple attempts of zooming in and randomly swiping to trigger it. Going to the beginning of the document with the first page on the rightĭouble-tapping near the center of the screen to zoom in Putting the device in landscape orientation We knew that a set of specific conditions had to be satisfied for it to occur:Ĭonfiguring the view controller to use a page curl transition style and double-page mode In short, the crash occurred when viewing documents and changing pages using the page curl transition style it was caused by an assertion failure inside UIPageViewController. Eventually, we managed to gain a vague understanding of the conditions that caused it. The issue had been open for more than a year, and we had multiple engineers attempting to resolve it. We had been gathering information about this crash for a long time before I took it on. This blog post describes my process of identifying it, reverse engineering UIKit to understand what was going on, and coming up with a fix. I took on the challenge of hunting down the root cause of this crash and addressing it. ![]() One such improvement was fixing an extremely hard-to-reproduce crash that, incidentally, was our top reported crash for a very long time. But we’ve also been consistently working hard on under-the-hood enhancements and bug fixes. ![]() Our most recent releases of PSPDFKit for iOS introduced many new features, such as Electronic Signatures, Instant Comments, and the revamped undo and redo architecture. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |