On 10/26/2011 04:13 PM, Tom Z wrote: > > > Thanks. I increased the stack size and the problem was gone. This > problem was hard to find for me, as when I step into the functions in > gdb, the locations where the problem occurs are different. > > > BTW, in your previous reply you mentioned debugging techniques such > as examining the registers and disassembling, can you suggesting some > readings that elaborate such techniques. I have a few questions > regarding such techniques, e.g., how do I interpret the meaning of > each register? By disassembling, do you mean looking at the assembly > codes?
The best I could find is this: http://www.urbanmyth.org/linux/oops/slides.html Which explains how to debug a kernel oops. The method transpose easily to user-space. In case of stack overflow, the stack pointer register should show an address not mapped, or mapped read-only. You can see a process mappings in /proc/pid/maps (if you want this file to exist in case of a segfault, install a signal for SIGSEGV which calls the pause() function). But if gdb does not modify the program behaviour, debugging with gdb is much easier. -- Gilles. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
