Line number of segmentation fault

Is there any gcc option I can set that will give me the line number of the segmentation fault?

I know I can:

1. Debug line by line
2. Put printfs in the code to narrow down.

Edits:

1. bt / where on gdb give No stack.
2. Helpful suggestion

I don't know of a gcc option, but you should be able to run the application with gdb and then when it crashes, type where to take a look at the stack when it exited, which should get you close.

$ gdb blah
(gdb) run
(gdb) where

Edit for completeness:

You should also make sure to build the application with debug flags on using the -g gcc option to include line numbers in the executable.

Another option is to use the bt (backtrace) command.

Here's a complete shell/gdb session

$ gcc -ggdb myproj.c
$ gdb a.out
gdb> run --some-option=foo --other-option=bar
(gdb will say your program hit a segfault)
gdb> bt
(gdb prints a stack trace)
gdb> q
[are you sure, your program is still running]? y
$ emacs myproj.c # heh, I know what the error is now...

Happy hacking :-)

You can get gcc to print you a stacktrace when your program gets a SEGV signal, similar to how Java and other friendlier languages handle null pointer exceptions. See my answer here for more details:

• how to generate a stacktace when my C++ app crashes ( using gcc compiler )

The nice thing about this is you can just leave it in your code; you don't need to run things through gdb to get the nice debug output.

If you compile with -g and follow the instructions there, you can use a command-line tool like addr2line to get file/line information from the output.

Run it under valgrind.

you also need to build with debug flags on -g

You can also open the core dump with gdb (you need -g though).

If all the preceding suggestions to compile with debugging (-g) and run under a debugger (gdb, run, bt) are not working for you, then:

• Elementary: Maybe you're not running under the debugger, you're just trying to analyze the postmortem core dump. (If you start a debug session, but don't run the program, or if it exits, then when you ask for a backtrace, gdb will say "No stack" -- because there's no running program at all. Don't forget to type "run".) If it segfaulted, don't forget to add the third argument (core) when you run gdb, otherwise you start in the same state, not attached to any particular process or memory image.
• Difficult: If your program is/was really running but your gdb is saying "No stack" perhaps your stack pointer is badly smashed. In which case, you may be a buffer overflow problem somewhere, severe enough to mash your runtime state entirely. GCC 4.1 supports the ProPolice "Stack Smashing Protector" that is enabled with -fstack-protector-all. It can be added to GCC 3.x with a patch.

There is no method for GCC to provide this information, you'll have to rely on an external program like GDB.

GDB can give you the line where a crash occurred with the "bt" (short for "backtrace") command after the program has seg faulted. This will give you not only the line of the crash, but the whole stack of the program (so you can see what called the function where the crash happened).

The No stack problem seems to happen when the program exit successfully.

For the record, I had this problem because I had forgotten a return in my code, which made my program exit with failure code.