understanding stack trace of a segmentation fault

问题

I am doing an snprintf and getting a seg fault.

when I loaded the core file on gdb like this: gdb my_executable core ; and did bt to get the backtrace, I got following:

Program terminated with signal 11, Segmentation fault.
#0  0x88207fc2 in memcpy () from /usr/lib/libc.so.6
(gdb) bt
#0  0x88207fc2 in memcpy () from /usr/lib/libc.so.6
#1  0x88205eb6 in __sfvwrite () from /usr/lib/libc.so.6
#2  0x881fbc95 in strchr () from /usr/lib/libc.so.6
#3  0xbfbe6c14 in ?? ()
#4  0xbfbe69d8 in ?? ()
#5  0x881ed91e in localeconv () from /usr/lib/libc.so.6
#6  0x881fec05 in __vfprintf () from /usr/lib/libc.so.6
#7  0x881f7d80 in snprintf () from /usr/lib/libc.so.6  
#8  0x08052b64 in my_function (files=0xbfbed710, filename=<value optimized out>) at myfile.c:1102
#9  0x08053bfb in main (argc=4, argv=0xbfbedd90) at myfile.c:225

I see such stack many times in case of seg fault but never understood correctly.

Just looking the calls in trace, can we tell what is going wrong?

NOTE: Please do not ask for more code. My motive is simply understand what the stack-trace like this means - irrespective of code. I see that on the top "memcpy" is failing. I want to understand when that can happen in this situation.

回答1:

You function does something at myfile.c:1102. This in turn tricks the standard library into illegally accessing memory. The operating system notices and slaps your program with sigsegv.

Common reasons, (as seen on Stackoverflow :)) ) are:

• Writing to read-only memory
• Using uninitialized pointers
• Accessing memory past the end of an allocated block

The long list of functions shows you who did it. So:

• my_function called snprintf
• which called __vfprintf
• ...

回答2:

I would suggest you to run your executable under Valgrind. It may output additionl call traces in case of problems in your code such as work with already freed memory. This usually helps to understand the reason of crash.

回答3:

It's just a trace of the calls. The first function call in the program will appear in the bottom, generally it will be main and subsequent calls to other functions (from inside main) will appear on top of it. If the new call calls another subroutine (function), it's stacked on top and the process continues.

GDB prints some useful information, considering it's available. The first column are the stack positions (top-bottom). Second column contains addresses of calls, and the remaining information contains the name of the function called and where it's located. Note that these vary a lot. Sometimes, the name of the symbol can't be retrieved and ?? () will appear as in #3 and #4 on your stack trace. When the source is available, also the line where the function is defined will appear, like at myfile.c:225.

来源：https://stackoverflow.com/questions/6726132/understanding-stack-trace-of-a-segmentation-fault