Menu
I'm new to embedded programming but I have to debug a quite complex application running on an embedded platform. I use GDB through a JTAG interface.
My program crashes at some point in an unexpected way. I suppose this happens due to some memory related issue. Does GDB allow me to inspect the memory after the system has crashed, thus being completely unresponsive?
595
asked Jan 03 '13 21:01
Memory leak detection tools. A number of tools help in the hunt for memory leaks. The most popular free ones are dmalloc and mpatrol. These tools provide debugging versions of the heap that record and check all allocations to facilitate analysis of leaks and dangling pointers.
There are three requirements for debugging an embedded or real-time system. They are Run control, Memory substitution and real time analysis. I. Run control is the ability to start, stop, peek, and poke the processor and memory.
Memory leaks, fragmentation, and even crosstalk can affect your memory units. If you're not prepared this could lead to individual system failures or even cascading failures. That's why it's important to test your memory and catch these faults, both in the testing process and during operation.
It depends on your setup a bit. In particular, since you're using JTAG, you may be able to set your debugger up to halt the processor when it detects an exception (for example accessing protected memory illegally and so forth). If not, you can replace your exception handlers with infinite loops. Then you can manually unroll the exception to see what the processor was doing that caused the crash. Normally, you'll still have access to memory in that situation and you can either use GDB to look around directly, or just dump everything to a file so you can look around later.
55
It depends on what has crashed. If the system is only unresponsive (in some infinite loop, deadlock or similar), then it will normally respond to GDB and you will be able to see a backtrace (call stack), etc. If the system/bus/cpu has actually crashed (on lower level), then it probably will not respond. In this case you can try setting breakpoints at suspicious places/variables and observe what is happening. Also simulator (ISS, RTL - if applicable) could come handy, to compare behavior with HW.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
