I'm working on a router and a process is core-ing due to memory
corruption.
It's very difficult to recreate core manually. But core is happening
intermittently.
All I have a core. I would like your suggestion to find the memory
corruption
by looking into core alone(with out reproducing it again).
Could please tell me checklists for solving this core?
c.l.c people can ignore following comment.
/* Your question is off topic in c.l.c -- try a platform-specific
newsgroup, or perhaps comp.programming.
How you debug a problem like this depends on what features
your platform has. For example, we don't know if you have a
file system, a display, memory management, back channels,
what C compiler if any, etc.
Following is an approach aimed at the situation where one bad
line of code is responsible for the problem being debugged.
To find the function where the problem occurs, create a
circular buffer in which you store procedure entry and
exit data. Put the buffer and its index at a known or fixed
address so you can find it in the core file. Each time you
make an entry in the buffer, check the integrity of any
areas that are getting corrupted, so you can break as
soon as possible after corruption. To get procedure entry/
exit/caller data, see the -finstrument-functions section in
<
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html>.
In your __cyg_profile_func_enter and __cyg_profile_func_exit
functions, store entry/exit/caller and other relevant data in
the circular buffer, and then check integrity.
After you find the guilty function, put a 'z' character at
the beginning of a few of the code lines of the function,
where 'z' stands for the name of a macro like the following:
#define z fprintf(stderr,"%s@%3d \n",__FILE__,__LINE__);
After you bracket the guilty line within a range of lines, fill in
more z's until you locate a specific guilty line. Note, put
check(__FILE__,__LINE__); in place of the fprintf() or before
the fprintf() if you don't have a display, or if you want to do
corruption checking at each line. */
Also see -fstack-check section in webpage mentioned above.
