I used the answer to this question How to detect if any external libraries are calling [UIDevice currentDevice] uniqueIdentifier]?
to get an log where uniqueIdentifier was being called. However I can't pull much useful information from the log. How can I determine what class or library is calling uniqueIdentifier.
* thread #7: tid = 0x2603, 0x01850690 UIKit`-[UIDevice uniqueIdentifier], stop reason = breakpoint 6.1
frame #0: 0x01850690 UIKit`-[UIDevice uniqueIdentifier]
frame #1: 0x02743663 libobjc.A.dylib`-[NSObject performSelector:] + 62
frame #2: 0x001038ff SmackTalk`CLSHostDataInit + 843
frame #3: 0x028b4014 libdispatch.dylib`_dispatch_client_callout + 14
frame #4: 0x028a52e8 libdispatch.dylib`_dispatch_root_queue_drain + 335
frame #5: 0x028a5450 libdispatch.dylib`_dispatch_worker_thread2 + 39
frame #6: 0x9a597e72 libsystem_c.dylib`_pthread_wqthread + 441
Does CLS refer to any framework you might have added? Seems like the best clue out of the log you posted.
You could try trial and error. Start with the most likely suspects like an analytics or advertising framework, unlink it and comment out dependent code and see if that breakpoint still gets hit.
Depending on how many libraries you're talking, it might also make sense to lookup the project pages for those libraries and check for how current their code is and how up-to-date your version of their code is. Best case would be that they've since updated their library and pulled out the UDID code and all you'd have to do is update to the latest version.
From the trace, it looks like the caller may be trying to mask the call by using -[NSObject performSelector:], and doing so inside a dispatch block. However, since you know that some library is making this call, you should be able to narrow down which one. For example, you can try this command on all your linked libraries:
$ strings libFoo.a | grep uniqueIdentifier
This should help figure out which library is likely calling the offending method.
Related
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've seen a handful of different crash reports coming in that all seem to be triggered when Core Text is calculating the size of some text in response to a call to [UIView sizeThatFits]. I suspect the crashes share some common cause, but I've only got a few stack traces and I don't know how to reproduce any of the problems myself, so I'm left guessing what sorts of problems could be triggering the crash.
In one case the crash is happening in an ABPeoplePickerNavigationController and the code on the stack is entirely Apple code. I've audited my code to make sure that UIKit/Core Text are only being used from the main thread.
I saw this tantalizing stack trace posted on the buzztouch forum, which looks very similar and also shares the "contacts" trigger.
frame #0: 0x007fe283 CoreText`TComponentFont::GetMinSideBearing(CGAffineTransform const&, bool) const + 43
frame #1: 0x0076b244 CoreText`TRun::GetLeftHangersGlyphCountAndWidth(long, unsigned long, TCharStream const&) const + 524
frame #2: 0x0077e7da CoreText`TLine::GetLeftHangersGlyphCountAndWidth(unsigned long const*) const + 234
frame #3: 0x0077e4b9 CoreText`TLine::GetBounds(unsigned long) const + 811
frame #4: 0x0077ace6 CoreText`CTLineGetBoundsWithOptions + 44
frame #5: 0x02059497 UIKit`-[UITableViewIndex _cacheAndMeasureTitles] + 984
frame #6: 0x02059ace UIKit`-[UITableViewIndex sizeThatFits:] + 131
On the forum, someone named Ofer left a post saying the crash had been fixed. I'm hoping Ofer might be kind enough to share some details about what they discovered they were doing to trigger the crash!
In my case the problem appears to have stemmed from the way I was loading icons using the FontAwesomeKit library, as described in his "Known Issues". I had the good luck of getting my app into a state where I could pretty regularly reproduce the problem, and applying the suggested workaround made the problem go away (of course, for all I know it could just be hiding).
I'm watching Paul Hegarty's iOS lessons on iTunes U.
I'm developing the first app of the course.
I am randomly getting the same error (Thread 1: signal SIGABRT), about once every two runs.
I placed breakpoints everywhere but the error seems to happen before anything gets called. I checked and re-checked my storyboard since it already happened to me that it was a problem with referenced outlets and that stuff, but everything seems fine. Also, it's so strange that it happens randomly and not programmatically.
I'm on Xcode 4.
I did a bt in lldb, but I keep getting this (same) cryptic error message (given that Matchismo is the name of the app):
(lldb) bt
* thread #1: tid = 0x1c03, 0x94b49a6a libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x94b49a6a libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x93ba5b2f libsystem_c.dylib`pthread_kill + 101
frame #2: 0x04a7f57b libsystem_sim_c.dylib`abort + 140
frame #3: 0x01bf3b4e GraphicsServices`GSRegisterPurpleNamedPort + 348
frame #4: 0x01bf369f GraphicsServices`_GSEventInitialize + 123
frame #5: 0x01bf3c1f GraphicsServices`GSEventInitialize + 36
frame #6: 0x0001bd99 UIKit`UIApplicationMain + 600
frame #7: 0x00002a0d Matchismo`main(argc=1, argv=0xbffff3ac) + 141 at main.m:16
frame #8: 0x00002935 Matchismo`start + 53
I don't even know if it's a meaningful question and if it can be actually answered. If not, I'm sorry. If it's necessary, I can paste the entire app code here, it's quite short actually.
Edit
I thought that pushing to a repo and linking the repo here could really make things easier for everyone :).
https://github.com/whatyouhide/Matchismo
I think the problem is situated inside CardGameViewController/CardMatchingGame. I'm not sure though.
I also had this error while doing Matchismo. After spending so much time, I found how to fix it. The way I fixed my error was by going in story board. Below the iPhone screen, there will be small yellow button. Right click on it and you will see that is causing error. Delete(x) it if there is yellow error sign.
If this does not fix your error then try to make new project and then replace its blank files with old files of your old project. I had same error in very beginning and by doing this program run without any error.
Other people suggests by restarting your laptop and running it again, reseting the iOS simulator, or changing iOS debugger (however this does not work in latest x code since there is only one debugger)
Hope this helps
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.