How to debug such memory corruption?

Question

int main () {
       allocating_resource();
       call_other_libs();
       ...
       release_resource();
       return 0;
}

After the program runs, the main returns.

And after it accessed returne 0 , the stack pointer points to a bad address in main(), then the executable crashed.

Program received signal SIGSEGV, Segmentation fault.

GI __libc_free(mem=0x3f21a843) at malloc.c:2020

I guess there are some illegal memory accesses, but the code base is too large to check. Review and analyse all the code is not realistic.

Disable some code is also unacceptable due to large code base.

With core dump there 's no hint I can use due to it's crashed at the main stack and after the return clause executed.

I know how to use gdb, but the project is so large that it seems to hard to find the root cause.

valgrind --tool=memcheck seems to no help.

How to solve such problem?

Answer 1

You can use GDB. This stackoverflow link has details about how to debug using GDB. If you google, you can get many such helpful links on GDB.
You can also use valgrind , if you are sure about memory related issues.

There is one more memory profiler called MemProf . It gives memory allocated for each function and can also detect issues. See the link for details.
There are also c++ specific tools for memory profiling like:
mempro and MTuner . You can use trial version for free.

Answer 2

Since we are not having some kind of code access here, I'll have to assume that in some magic way free is called when the scope of main is destroyed (maybe the use of smart pointers? maybe some sophisticated macro definitions... can't really tell). I would try to recreate the problem in the following manner:

int main () 
{
       {
           allocating_resource();
           call_other_libs();
           ...
           release_resource();
       }
       return 0;
}

or

  int main()
  {
    mainhelper();
    return 0;
  }

where mainhelper will contain the main code.

Hopefully after those steps the problem will persist and the logs won't be completely damaged, as you suggest, because the program is terminating.

also, try to play with the optimization flags (more like in disabling it) and add -ggdb3 debug flag (assuming gcc here). Maybe it will help you in some bizarre way.

Some other posts concerning this matter, if you haven´t checked them out yet:

segmentation fault after main returns

Program receives SIGSEGV error after return 0

they are all stating more of the same: valgrind should be able to deliver an answer.