understanding stack trace of a segmentation fault

Question

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.

Socialite

Answer 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
• ...

Uriniferous

Thanks for the "common reasons". I am looking for an exhaustive list of things that can cause such segfault. Appreciate your help :) – Socialite

Answer 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.

Loyal

Thanks. Do you happen to have a good starter link/pointer for Valgrind? – Socialite

For getting started with Valgrind there is Quick Start Guide. For more detailed info there is Valgrind User Manual. Pay attention to Memcheck in User Manual. This is memory error detector. It can detect the number of memory related problems in code. – Loyal

Answer 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.

Acuate