I have integrated the PDFTron library in my iOS Application and followed the instruction mentioned in documentation(https://blog.pdftron.com/2013/07/19/getting-started-on-ios/), application is working fine when I am using the local pdf files but application is crashing each time in below scenario
1) Downloaded pdf files from url, stored in document directory and display using the PDFTron.
I have got following the error log:
function -[PTPDFViewCtrl RemoveAllThumbnails], file
/Users/PDFTron/PDFNet_6.5/PDFTron/iOS/Control/PDFViewCtrl.m, line
1744. (lldb) bt
* thread #23: tid = 0x12491, 0x000000010aa43002 libsystem_kernel.dylib__pthread_kill + 10, stop reason = signal
SIGABRT
frame #0: 0x000000010aa43002 libsystem_kernel.dylib__pthread_kill + 10
frame #1: 0x000000010aa095c5 libsystem_pthread.dylibpthread_kill + 90
frame #2: 0x000000010a799cec libsystem_c.dylibabort + 129
frame #3: 0x000000010a761bdc libsystem_c.dylib__assert_rtn + 321
frame #4: 0x00000001041177c4 BW - Internal-[PTPDFViewCtrl RemoveAllThumbnails] + 94
frame #5: 0x0000000104113daf BW - Internal`-[PTPDFViewCtrl SetDoc:] + 178
I have tried lock and unlocking the document but still I am getting same error and any help is appreciated.
PDFNet can "stream" PDF files from a remote URL using the OpenURL: method. Are you using this method, or doing it some other way? Either way, please contact us at support#pdftron.com, and we will work with you to sort it out.
Related
The following code exports a file from my app's 'tmp' folder to other apps using UIActivityViewController.
private func exportFile(_ fileURL: URL) {
let items: [Any] = [fileURL]
let activityViewController = UIActivityViewController(activityItems: items, applicationActivities: nil)
present(activityViewController, animated: true, completion: nil)
}
This code was working fine and I could export to iCloud, Google Drive, Mail, Outlook and iZip (the latter using 'Copy to iZip').
However, my app has recently started crashing after selecting 'Copy to iZip' when exporting, though exporting to the other apps works fine. Between it working and crashing there have been updates to iOS, iZip and my app.
Crashlytics reports the following, but this looks deep in iOS and it's difficult to know what the root cause of the problem is:
Fatal Exception: NSInvalidArgumentException
*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil
ShareSheet __79-[UIActivityViewController willPerformInServiceActivityWithRequest:completion:]_block_invoke_3
This occurs on an iPhone running iOS 13.3.1
Debugger report on breaking on NSInvalidArgumentException:
> (lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000189ffdf6c libobjc.A.dylib`objc_exception_throw
frame #1: 0x000000018a32c360 CoreFoundation`_CFThrowFormattedException + 112
frame #2: 0x000000018a32b9f4 CoreFoundation`-[__NSArrayM insertObject:atIndex:].cold.1 + 48
frame #3: 0x000000018a1ae120 CoreFoundation`-[__NSArrayM insertObject:atIndex:] + 1104
frame #4: 0x0000000195914e80 ShareSheet`__79-[UIActivityViewController willPerformInServiceActivityWithRequest:completion:]_block_invoke_3 + 1512
frame #5: 0x00000001089497fc libdispatch.dylib`_dispatch_call_block_and_release + 24
frame #6: 0x000000010894abd8 libdispatch.dylib`_dispatch_client_callout + 16
frame #7: 0x0000000108958c34 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 1316
frame #8: 0x000000018a2545e4 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
frame #9: 0x000000018a24f5d8 CoreFoundation`__CFRunLoopRun + 2004
frame #10: 0x000000018a24eadc CoreFoundation`CFRunLoopRunSpecific + 464
frame #11: 0x00000001941ef328 GraphicsServices`GSEventRunModal + 104
frame #12: 0x000000018e35c63c UIKitCore`UIApplicationMain + 1936
* frame #13: 0x00000001024f1078 xApp`main at AppDelegate.swift:41:7
frame #14: 0x000000018a0d8360 libdyld.dylib`start + 4
(lldb)
Code at frame #4 breakpoint (0x195914e80):
> WTFLogLevel, WTF::Logger::LogSiteIdentifier const&, char const (&) [7], unsigned long const&) (.cold.1)
0x195914e80 <+1512>: mov x28, x23
0x195914e84 <+1516>: ldr x0, [x23, #0xba0]
0x195914e88 <+1520>: ldr x1, [sp, #0x38]
0x195914e8c <+1524>: mov x2, x25
0x195914e90 <+1528>: mov x3, x20
0x195914e94 <+1532>: bl 0x193904be4 ; symbol stub
Any idea what the problem might be? I'm not sure whether it's a problem with my app, iOS or iZip.
Thanks to the suggestion from #koen, I contacted iZip support and had a very quick and helpful response. It also ties in with #WILL K. 's suggestion of trying a different directory.
The problem basically seems to be associated with directory permissions. Apparently some apps like iZip open the shared file in situ and so need permission to do so. As can be seen here https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html , the Documents/ directory "can be made available to the user through file sharing" whereas the tmp/ directory is more restricted.
So instead of using the tmp/ directory I tried using the Documents/ directory and the problem was solved. Thanks to iZip support for their rapid response and highlighting the issue with permissions.
For interest, on using the /Documents folder, more options came up for sharing with other apps.
There is also a useful article on how app extensions work (host apps, app extensions and container apps) here:
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/ExtensionOverview.html
I have an app that runs fine on iOS, but when running with catalyst, it gives me this crash intermittently if I swipe to another virtual Desktop on macOS, and then back, for about 10 times. It mostly happens on a UICollectionViewController
This is the backtrace:
(lldb) bt
* thread #5, queue = 'com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
* frame #0: 0x00007fff68c373ae libxpc.dylib`___xpc_activity_dispatch_block_invoke.107.cold.3 + 19
frame #1: 0x00007fff68c1ecdb libxpc.dylib`___xpc_activity_dispatch_block_invoke.107 + 746
frame #2: 0x00000001010377b3 libdispatch.dylib`_dispatch_call_block_and_release + 12
frame #3: 0x000000010103878f libdispatch.dylib`_dispatch_client_callout + 8
frame #4: 0x000000010103fd31 libdispatch.dylib`_dispatch_lane_serial_drain + 777
frame #5: 0x0000000101040ae8 libdispatch.dylib`_dispatch_lane_invoke + 438
frame #6: 0x000000010104df2e libdispatch.dylib`_dispatch_workloop_worker_thread + 681
frame #7: 0x00000001010c4053 libsystem_pthread.dylib`_pthread_wqthread + 290
frame #8: 0x00000001010c3eb3 libsystem_pthread.dylib`start_wqthread + 15
(lldb)
I have tried reviewing the codes, adding print statements, adding breakpoints, commenting out certain parts etc, trying to figure out which part of my code causes this, but failed so far.
I am using NSPersistentCloudKitContainer from iOS 13. Does the stack trace points to a bug inside there?
I've wasted so much time trying to understand the source of the problem and hope that this answer helps many others.
This problems seems to persist now since a long time and has not been fixed, nor understood. But the big hint I've read in the comments:
This crash happens only when the app is run from within Xcode.
Another important hint: You can can run your build product directly from Finder without crashing. Even if it is a "Debug" build.
Based on this, I've come to the conclusion that the problem is related to the Debug execution environment and I found the solution: Disable "Debug XPC services used by this application"
There must be some bug in the debugging code used by this option.
You can find this option in your targets scheme.
Click on your target in the window bar
Select "Edit Scheme..."
Make sure "Run" is selected and remove the checkmark for "Debug XPC services used by this application"
I hope this helps everybody!
I'm working on upgrading an old project to work on newer versions of iOS, but I keep getting a crash on the launch screen with this error:
error: memory read failed for 0x7c37d3000
And
Thread 4: EXC_BAD_ACCESS (code=257, address=0x1c7c37d309d)
To find out where in the code this was, I enabled zombie objects, and set a breakpoint for all exceptions. When the app crashes, the breakpoint does not highlight a section of code, but instead does this:
Image of breakpoint navigator
It says something about libobjc.A.dylib, and libc++abi.dylib, so I am assuming this is not part of my code? Also, clicking on the breakpoint does not lead me to a place in code like people say it usually does.
Here's the result of bt in the lldb console (backtrace):
* thread #4, stop reason = EXC_BAD_ACCESS (code=257, address=0x1c7c37d309d)
* frame #0: 0x00000007c37d309d
I read that from this back trace you can determine a method or file etc but this output does not seem to have that.
How can I determine where exactly in the code this error is coming from? Let me know if I should provide anything else, as I am new to this site. Thanks!
EDIT: I should probably mention that the app crashes with this on simulator: Error
Here's the backtrace for that error:
> * thread #3, stop reason = signal SIGABRT * frame #0: 0x0000000107d5cb66 libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x0000000107d96080 libsystem_pthread.dylib`pthread_kill + 333
> frame #2: 0x00000001012b7405 libclang_rt.tsan_iossim_dynamic.dylib`wrap_pthread_kill + 325
> frame #3: 0x0000000107b09c45 libsystem_c.dylib`abort + 127
> frame #4: 0x00000001012b669c libclang_rt.tsan_iossim_dynamic.dylib`wrap_abort + 108
> frame #5: 0x00000001008d5c0f GiFmojo`inittls + 431
> frame #6: 0x00000001008d5a32 GiFmojo`runtime.etext + 98
> frame #7: 0x00000001006fe19c GiFmojo`runtime.rt0_go + 140
> frame #8: 0x0000000107d93661 libsystem_pthread.dylib`_pthread_body + 340
> frame #9: 0x0000000107d9350d libsystem_pthread.dylib`_pthread_start + 377
> frame #10: 0x0000000107d92bf9 libsystem_pthread.dylib`thread_start + 13
The difference in crash reasons is very confusing.
EDIT: Here's the screenshot of the debug navigator:
EDIT: I disabled zombie objects and it now alternates between Thread 4 and Thread 5, with error:
error: memory read failed for 0xaeb3f7600
Thread 5: EXC_BAD_ACCESS (code=257, address=0x20aeb3f7693)
For Thread 5. Is there a reason for this?
Hey possible problem is debug-disassembly option could you
go to debug tab -> Debug Workflow -> Always show debug disassembly
and uncheck that ?
It seems like you have memory access errors, such as reading unreadable location, writing to unallocated (or already freed) location, and so on.
There are debugging technique for this kind of problems, but it's very difficult.
Take a look at this document: Enabling the Malloc Debugging Features
Start with malloc guard if possible(locating bad write), last resort is the searching the offending memory address from the malloc logging output.
Try using "Symbolic Breackpoint" in the "Breackpoints" tab. Very often it helps to find the place of the crash of the application. Hope to help
I have an iOS app which was running fine until yesterday and suddenly started to crash with Thread 1: signal SIGABRT at this point:
class AppDelegate: UIResponder, UIApplicationDelegate {
Having no idea of the cause I typed bt in the debugging console and got this:
(lldb) bt
* thread #1: tid = 0xda342, 0x0000000194637270 libsystem_kernel.dylib`__pthread_kill + 8, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x0000000194637270 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001946d5170 libsystem_pthread.dylib`pthread_kill + 112
frame #2: 0x00000001945aeb18 libsystem_c.dylib`abort + 112
frame #3: 0x000000018badf2ec GraphicsServices`_GSRegisterPurpleNamedPortInPrivateNamespace + 424
frame #4: 0x000000018bade1d4 GraphicsServices`_GSEventInitializeApp + 140
frame #5: 0x0000000186c86c38 UIKit`UIApplicationMain + 712
* frame #6: 0x00000001000592f0 TheApp`main + 164 at AppDelegate.swift:13
frame #7: 0x000000019451ea08 libdyld.dylib`start + 4
(lldb)
Browsing the net for similar issues I have read it may be due to some problems related to the StoryBoard, but since I am doing everything programmatically I have some doubts that it applies to my case. I have also tried to use an exception break point just in case, but with no success.
I have even remade the project, the problem is still there. It seems something goes wrong even before my code starts to execute. I wonder what I can check.
Anyway if someone can give me a hint on what may be the issue, or on how to further investigate, that would be much appreciated.
Using iOS 6.1 my App crashes regulary, directly after startup, when it attempts to make several HTTP-Requests, but it works fine on any OS < 6.1.
I'm experiencing
EXC_BAD_ACCESS crashes in the strlen function called from the Queue : com.apple.CFURLCACHE_work_queue, everytime my App is started, except for the first time.
I could resolve the issue by clearing the NSURLCache, directly after the app started:
[[NSURLCache sharedURLCache] removeAllCachedResponses];
Does anyone else experience these crashes? Could there be some issue in the application code causing these crashes? Or should this be a bug filed to apple?
Experiencing a similar crash since iOS 6.1 with a newly installed application. The difference is that the crash occurs when tapping a text cell in a table view. No web requests are being made at this time.
This is the bt:
thread #4: tid = 0x2903, 0x3ae7ad74 libsystem_c.dylib`strlen + 28, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x3ae7ad74 libsystem_c.dylib`strlen + 28
frame #1: 0x3ac6be24 libsqlite3.dylib`___lldb_unnamed_function282$$libsqlite3.dylib + 1232
frame #2: 0x3ac74a5e libsqlite3.dylib`sqlite3_file_control + 174
frame #3: 0x328493fe CFNetwork`__CFURLCache::RecreateEmptyPersistentStoreOnDiskAndOpen_NoLock() + 30
frame #4: 0x32849000 CFNetwork`__CFURLCache::RecreateEmptyPersistentStoreOnDiskAndOpen() + 44
frame #5: 0x327f9488 CFNetwork`__CFURLCache::OpenDatabase() + 192
frame #6: 0x32846a72 CFNetwork`__CFURLCache::ProcessCacheTasks0(bool) + 358
frame #7: 0x32846900 CFNetwork`__CFURLCache::ProcessCacheTasks(bool) + 36
frame #8: 0x3284681e CFNetwork`__CFURLCache::_CFURLCacheTimerCallback0() + 358
frame #9: 0x328466ac CFNetwork`__CFURLCache::_CFURLCacheTimerCallback(void*) + 32
frame #10: 0x328490fc CFNetwork`__SignalWorkerTaskToPerformWork_block_invoke_0 + 12
frame #11: 0x3ae4611e libdispatch.dylib`_dispatch_call_block_and_release + 10
frame #12: 0x3ae49ece libdispatch.dylib`_dispatch_queue_drain$VARIANT$mp + 142
frame #13: 0x3ae49dc0 libdispatch.dylib`_dispatch_queue_invoke$VARIANT$mp + 40
frame #14: 0x3ae4a91c libdispatch.dylib`_dispatch_root_queue_drain + 184
frame #15: 0x3ae4aac0 libdispatch.dylib`_dispatch_worker_thread2 + 84
frame #16: 0x3ae7aa10 libsystem_c.dylib`_pthread_wqthread + 360
frame #17: 0x3ae7a8a4 libsystem_c.dylib`start_wqthread + 8
Reported this as a TSI to Apple, it was reviewed and they requests that I log this as a bug, still need to do this.
Interestingly enough the solution which you found also helped me, clearing the cache at launch solved this problem.
This is only half an answer, but I'm running into a very similar problem whilst running my unit tests. Bizarrely, this only seemed to start happening today.
The full details of my issue are outlined in this Apple dev forums thread.
The common link between our problems appears to be the call to RecreateEmptyPersistentStoreOnDiskAndOpen_NoLock(). If my understanding of CFURLCache is correct, and based on the backtrace, it uses a sqlite3 database internally as a cache. I'd assume this function call creates the empty sqlite3 database on disk.
I was able to repeatedly and consistently stop my tests crashing by deleting the simulator's Library/Caches directory (~/Library/Application Support/iPhone Simulator/6.1/Library/Caches) and make the crash return by re-creating that directory.
Deleting the entire simulator home directory and letting it be recreated by launching my app in the simulator would also fix and re-create the issue.
I'm guessing this is an OS bug; the curious thing is why for me, it only just started happening.