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.
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
Summary: I got the message:
AddressSanitizer debugger support is active. Memory error breakpoint has been installed and you can now use it in the 'memory history' command.
What is the "memory history" command, and how exactly do I use it?
Details:
I had a bit of code that had a memory warning, which resulted to a crash.
I turned on the Address Sanitizer by going "Edit Scheme" > "Run" > "Enable Address Sanitizer".
Upon turning it on and running the same bit of code again, the crash didn't happen anymore, but the message appeared.
What does it mean, and what exactly is the memory history command? How do I use it? I have searched, but I haven't found anything that answers my question.
Running under Address Sanitizer allows you to see how were objects allocated. The memory history command needs a pointer/address and it will show how that object was allocated (a historical stacktrace of the allocation):
(lldb) po self
<MasterViewController: 0x61800000e080>
(lldb) memory history 0x61800000e080
thread ... name = 'Memory allocated at'
frame #0: 0x00000001051bba97 libclang_rt.asan_iossim_dynamic.dylib`wrap_calloc + 199
frame #1: 0x00000001064362fd libobjc.A.dylib`class_createInstance + 84
frame #2: 0x0000000106440dc7 libobjc.A.dylib`_objc_rootAlloc + 41
frame #3: 0x00000001072d6d25 UIKit`-[UIClassSwapper initWithCoder:] + 175
frame #4: 0x00000001074c731b UIKit`UINibDecoderDecodeObjectForValue + 683
...
It even works on already-deallocated objects, where it also shows the deallocation backtrace! This is extremely useful when you're accidentally accessing an already freed object.
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.