What exactly is the "memory history" command? - ios

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.

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

Disabling Zombies causes EXC_BAD_ACCESS

I am getting a crash in the app with the following stack trace-
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x39dfa66a objc_release + 9
1 libobjc.A.dylib 0x39dfb0d7 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
2 CoreFoundation 0x2f4a6c69 _CFAutoreleasePoolPop + 16
3 CoreFoundation 0x2f53c1cb __CFRunLoopRun + 1306
4 CoreFoundation 0x2f4a6f0f CFRunLoopRunSpecific + 522
5 CoreFoundation 0x2f4a6cf3 CFRunLoopRunInMode + 106
6 GraphicsServices 0x343ff663 GSEventRunModal + 138
7 UIKit 0x31df216d UIApplicationMain + 1136
8 Batted 0x0009db07 main (main.m:16)
The crash occurs when zombies are not enabled in the Scheme's diagnostics options. However, when I enabled it the crash doesn't occur.
I have read some of the other Q&A regarding this, and all of them seem to advice that once this behavior is seen, enable the zombies and run the Zombie Profile Instruments on the Simulator.
I tried that, but Instruments doesn't seem to indicate anything wrong and the app works.
Any clue to what else can be done here to root-cause this issue?
I am using XCode 5.1 with iOS 7.1 in Simulator.
UPDATE 1
Found the offending code causing the problem but I am still not sure why it is causing the problem.
I am using CoreData, and in subclass of the NSManagedObject, I have -
- (void)willTurnIntoFault;
{
[super willTurnIntoFault];
if ([self observationInfo])
{
BNLogInfo(#"%# has observers:\n%#", [self objectID], [self observationInfo]);
}
}
In the above code, [self observationInfo] is the offending line.
When the app starts up, I loop over some of the NSManagedObjects in an enumeration block and set some property on it, which in turn fires the willTurnIntoFault method. Once the enumeration block completes, the crash happens.
The mystery is that the crash doesn't happen inside this method, but without this method subclassed everything runs fine.
The Q&As say to enable zombies (or run under the Zombies instrument) because a zombie often causes this sort of error.
But it's not the only cause.
Your program is corrupting the heap. Most likely it's overwriting the isa pointer (the class pointer) in some object that's in the autorelease pool, so when the run loop drains the autorelease pool, objc_release tries to dereference the bogus isa pointer and crashes.
Enabling zombies can mask an error like this because, with zombies, the runtime never actually frees objects. This means you end up with lots of parts of the heap that don't get used (unless you try to send a message to a zombie), so they never cause trouble if you corrupt them.
These sorts of crashes can be very difficult to debug, but there's a tool called “guard malloc” that sometimes helps. From the menu bar, choose Product > Scheme > Edit Scheme. Click the Run action in the list on the left. Then click the Diagnostics tab. Turn on the “Enable Guard Malloc” option. Then try to reproduce the crash. Guard malloc will detect certain types of heap corruption immediately and stop the program on the corrupting instruction.

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.

iOS first steps - getting the annoying SIGABRT error

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

Resources