iOS first steps - getting the annoying SIGABRT error - ios

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

Related

EXC_BAD_INSTRUCTION from com.apple.xpc.activity.com.apple.cloudkit.scheduler.com.apple.coredata.cloudkit.activity.export

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!

iOS app crashes with EXC_BAD_ACCESS, Exception breakpoint not pointing to code

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

What sorts of problems cause Core Text crashes in calls to `sizeThatFits`?

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).

only (lldb) output in debug area, no other message

I got a rare problem that randomly when I ran my app in xcode, the simulator will stop and in the debug area only "(lldb)" is shown. It is random because when I ran again without modifying my code, it will run. What could have been the problem? I tried it in my other projects but still the same. Thank you.
xcode 4.6.2
Mountain Lion 10.8.4 (lldb error starts after updating 10.8.4 from 10.8.3, I don't know if this has some impact on xcode)
update1 - result from Douglas
(lldb) bt
* thread #1: tid = 0x1c03, 0x94f06a6a libsystem_kernel.dylib`__pthread_kill + 10, stop reason = signal SIGABRT
frame #0: 0x94f06a6a libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x907b1b2f libsystem_c.dylib`pthread_kill + 101
frame #2: 0x018db57b libsystem_sim_c.dylib`abort + 140
frame #3: 0x01f45b4e GraphicsServices`GSRegisterPurpleNamedPort + 348
frame #4: 0x01f4569f GraphicsServices`_GSEventInitialize + 123
frame #5: 0x01f45c1f GraphicsServices`GSEventInitialize + 36
frame #6: 0x0027ed99 UIKit`UIApplicationMain + 600
frame #7: 0x00001ccd sampleapp`main(argc=1, argv=0xbffff3a0) + 141 at main.m:16
In the debug area, after you see the lldb, type in bt, this will show you the crash log. Hopefully this will give you some insight as to what caused the crash/stop.
I just posted the same question and seemed to have fixed my own issue:
SIGABRT Error - Exactly after 3rd Run (both iPhone & iPad Simulators)
This appears to have resolved my issue:
Update your scheme by selecting Product > Scheme > Edit Scheme, and choose the GDB debugger for your debug scheme from the Info Tab.
The default was: LLDB
Be aware of the 2 debuggers: GDB Vs LLDB debuggers
I had the same output with only "(lldb)" being displayed. I could re-create the app crashing, though I couldn't really see why the certain steps should cause the app to crash? However, (from my initial tests) I am unable to crash the app running on an actual phone, which suggests to me something is dodgy with the simulator.
Xcode 7/7.2.1
iPhone 5S running iOS 9.2.1
When I ran into a similar issue, it was because I somehow accidentally set a breakpoint on a line of code. Just click on the blue ribbon on the line of code to unset it.

How can I find the file calling uniqueIdentifier on UIDevice?

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.

Resources