As announced at WWDC 2015, Clang Address Sanitizer is being brought to Xcode and OS X.
Session 413: Advanced Debugging and the Address Sanitizer
How do you enable Clang Address Sanitizer for your Xcode project?
Address Sanitizer has been added as a new feature in Xcode 7.
Use the Runtime Sanitization > Enable Address Sanitizer flag in your scheme to enable the option.
git will then shown this change to your .xcscheme file:
enableAddressSanitizer = "YES"
From the New Features in Xcode 7 document:
Address Sanitizer. Xcode 7 can build your app with instrumentation designed to catch and debug memory corruption using the address sanitizer.
Objective-C and C code is susceptible to memory corruption issues such as stack and heap buffer overruns and use-after-free issues. When these memory violations occur, your app can crash unpredictably or display odd behavior. Memory corruption issues are difficult to track down because the crashes and odd behavior are often hard to reproduce and the cause can be far from the origin of the problem.
You enable the address sanitizer in the build scheme. Once enabled, added instrumentation is built into the app to catch memory violations immediately, enabling you to inspect the problem right at the place where it occurs. Other diagnostic information is provided as well, such as the relationship between the faulty address and a valid object on the heap and allocation/deallocation information, which helps you pinpoint and fix the problem quickly.
Address sanitizer is efficient—fast enough to be used regularly, as well as with interactive applications. It is supported on OS X, in the Simulator, and on iOS devices.
Related
I am currently using IAR EWARM 9.10 to develop an application for Kinetis K66. I am in the process of debugging a hard fault and I noticed that when I inspected certain locations - using EWARM's memory view - in the K66 Flash, the contents were reported as double dashes ('--'). How should I be interpreting this?
Example attached...
The dashes (-) in the Memory visualization window means unmapped memory.
In a Kinetis device where the installed Flash memory ends at 0x000FFFFF, the "Memory 1" window shows up like this on the end of the region:
For the Kinetis devices, the flash memory available for the user's code is discontiguous and within 0x0000_0000~0x0000_03FF | 0x0000_0410~END_OF_FLASH.
This is due a "flash configuration" region (0x0000_0400~0x0000_040F) reserved for the FlashConfig section.
For a similar device, using IAR EWARM 9.30:
When I write C++ with MS Visual Studio, I use the following statement to check my heap for corruptions. This has been an excellent tool in homing in on problems:
_ASSERTE( _CrtCheckMemory() );
Basically you can scatter the above statement around your code to check the consistency of the heap.
Is there something similar that can be used in Android NDK programs to identify heap corruption at runtime - before I crash with a tombstone dump?
In Linux, similar functionality can be achieved by mcheck. But, unfortunately, this can't be used on Android (however, here and here can be find mcheck.h for Android)
If your device rooted, you can try this:
Valgrind
AddressSanitizer
am dumpheap <pid> <path/where/to/save/dump> (obtain dump of process's native heap)
For dump analyzation, you can try use deprecated Android Monitor (this link should help to enable native heap dump)
Is there any memory debugger for linux kernel?
We have issues with "NULL pointer dereference" kernel oops among other crashes on android/linux arm based hardware.
Thanks
Modern kernels contain a great deal of built-in diagnostic tools (those are available in "Kernel hacking" sub-menu of the kernel source configuration tool). However, on embedded targets one has also an option of using gdb with a good jtag debugger, such as Abatron BDI series (this will, of course, allow for the most precise diagnostics, including diagnostics of interrupt related problems).
In the absence of hardware debugger, the following options can be quite handy to detect memory leaks (don't forget to compile the kernel with "Compile the kernel with debug info" and "Compile the kernel with frame pointers" set):
Kernel memory leak detector - useful in catching kmalloc/kfree errors.
KGDB (with suboptions) - this will enable a built-in gdb server inside the kernel, which can be accessed from a gdb front-end over a serial port. There's also a KGDB_KDB option to do the same manually (by omitting the gdb front end and using a human manageable protocol).
kmemcheck - requires the least of human interaction and the most machine resources, but can be handy in doing initial memory related problem analysis.
There are plenty of other diagnostics options, useful with more specific classes of problems. Most of them are reasonably documented both with kernel configuration tool snippets as well as with separate documents in Documentation/ sub-directory of the source (+ various online publications).
I'm developing a KEXT on mac using Xcode, After every compile I'm changing permissions through terminal and load the KEXT, then reading results from console app. Some of the mistakes in development giving system a kernel panic and I have to restart my mac, this is so annoying. I was wondering if there is a better way to develop and debug a KEXT?
This is too big a topic for an answer, but it is at least well documented, look at these documents from Apple:
When Things Go Wrong: Debugging the Kernel
Debugging a Kernel Extension with GDB
Technical Note TN2063: Understanding and Debugging Kernel Panics
Also note that you can get the output from kprintf() logging calls via Firewire (using the fwkpfv command-line utility on the other Mac) or Serial Port (mainly useful for testing in VMs, as modern Macs don't have serial ports). kprintf is synchronous, so unlike the kernel.log you will see the debug output even if it occurs immediately before a crash.
I want to know if an executable supports the common security protections such as NX flag, stack cookies or ASLR. It seems ASLR is set at the OS level but how do you know it is enabled? On Windows some executable do not support ASLR so I was wondering how you can determine this on Mac OS X.
First of all ALSR used in OSX 10.6 and below did not randomize all regions of memory. As far as I know ASLR is enabled for all running executables. This is very easy to test for, just fire up a debugger set a break point and record any memory address on the stack. Restart the application and see if that same variable has the same memory address.
I think in OSX 10.7 they started randomizing the dynamic linker. Which linux, bsd, and even windows systems have been doing for a number of years.
For OSX, linked libraries ASLR can be tested for using executing export DYLD_PRINT_SEGMENTS=1 and then running a command. The TEXT memory region is the base address for the library. Run this command twice against any binary. If the base address is different between the two execution then ASLR's dirty work is to blame.
Stack cookies are an entirely different ballgame. This is a compiler level protection and will vary based on the application. Modern versions of GCC should default to stack carnies enabled. Again you should consult your debugger to see if a specific application is using canaries. Just examine the stack frame of any function to see if there is a random value inserted between the locally declared variables and the return address.
As far as the NX flag goes, you should assume any system made after 1999 uses this trivial form of protection. But, this is by far the most simple protection for you to bypass, just ret-to-libc or employ an ROP chain (because of aslr).