I know there's no standard C function to do this. I was wondering what are the techniques to to this on Windows and *nix? (Windows XP is my most important OS to do this on right now.)

- 347,512
- 102
- 1,199
- 985

- 25,207
- 17
- 54
- 57
-
I have tested several methods in detail at: https://stackoverflow.com/questions/3899870/print-call-stack-in-c-or-c/54365144#54365144 – Ciro Santilli OurBigBook.com Jan 25 '19 at 12:20
9 Answers
glibc provides backtrace()
function.
http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
-
10glibc FTW... again. (This is yet another reason why I consider glibc to be the absolute gold standard when it comes to C programming (that and the compiler that goes with it).) – Trevor Boyd Smith Sep 09 '11 at 17:53
-
7But wait there's more! The backtrace() function only provides an array of void * pointers representing the callstack functions. "That isn't very useful. arg." Fear not! glibc provides a function that converts all the void * addresses (the callstack function addresses) into human readable string symbols. `char ** backtrace_symbols (void *const *buffer, int size)` – Trevor Boyd Smith Sep 09 '11 at 17:55
-
I think void* to symbol name for the functions --> IMO that is some pretty awesome voodoo-blackmagic. – Trevor Boyd Smith Sep 09 '11 at 17:55
-
1Caveat: only works for C functions, I think. @Trevor: It's just looking up syms by address in the ELF table. – Conrad Meyer Oct 16 '11 at 00:20
-
2There is also `void backtrace_symbols_fd(void *const *buffer, int size, int fd)` which can send the output directly to stdout/err for example. – wkz Apr 24 '12 at 13:47
-
2`backtrace_symbols()` sucks. It requires exporting all symbols and it does not support DWARF (debugging) symbols. libbacktrace is a much better option in many (most) cases. – Erwan Legrand Feb 08 '18 at 11:18
-
You shall compile with -rdynamic option to get symbolic names in `backtrace_symbols`. – Marian Aug 14 '18 at 11:19
There's backtrace()
, and backtrace_symbols()
:
From the man page:
#include <execinfo.h>
#include <stdio.h>
...
void* callstack[128];
int i, frames = backtrace(callstack, 128);
char** strs = backtrace_symbols(callstack, frames);
for (i = 0; i < frames; ++i) {
printf("%s\n", strs[i]);
}
free(strs);
...
One way to use this in a more convenient/OOP way is to save the result of backtrace_symbols()
in an exception class constructor. Thus, whenever you throw that type of exception you have the stack trace. Then, just provide a function for printing it out. For example:
class MyException : public std::exception {
char ** strs;
MyException( const std::string & message ) {
int i, frames = backtrace(callstack, 128);
strs = backtrace_symbols(callstack, frames);
}
void printStackTrace() {
for (i = 0; i < frames; ++i) {
printf("%s\n", strs[i]);
}
free(strs);
}
};
...
try {
throw MyException("Oops!");
} catch ( MyException e ) {
e.printStackTrace();
}
Ta da!
Note: enabling optimization flags may make the resulting stack trace inaccurate. Ideally, one would use this capability with debug flags on and optimization flags off.
-
@shuckc only for converting the address to a symbol string, which can be done externally using other tools if need be. – Woodrow Barlow Jul 07 '16 at 19:57
For Windows check the StackWalk64() API (also on 32bit Windows). For UNIX you should use the OS' native way to do it, or fallback to glibc's backtrace(), if availabe.
Note however that taking a Stacktrace in native code is rarely a good idea - not because it is not possible, but because you're usally trying to achieve the wrong thing.
Most of the time people try to get a stacktrace in, say, an exceptional circumstance, like when an exception is caught, an assert fails or - worst and most wrong of them all - when you get a fatal "exception" or signal like a segmentation violation.
Considering the last issue, most of the APIs will require you to explicitly allocate memory or may do it internally. Doing so in the fragile state in which your program may be currently in, may acutally make things even worse. For example, the crash report (or coredump) will not reflect the actual cause of the problem, but your failed attempt to handle it).
I assume you're trying to achive that fatal-error-handling thing, as most people seem to try that when it comes to getting a stacktrace. If so, I would rely on the debugger (during development) and letting the process coredump in production (or mini-dump on windows). Together with proper symbol-management, you should have no trouble figuring the causing instruction post-mortem.

- 47,778
- 10
- 99
- 143
-
2You're right about it being fragile to attempt memory allocation in a signal or exception handler. One potential way out is to allocate a fixed amount of "emergency" space at program start, or use a static buffer. – j_random_hacker Feb 19 '09 at 12:30
-
Another way out is creating a coredump service, which runs independently – Kobor42 Jul 13 '12 at 07:59
You should be using the unwind library.
unw_cursor_t cursor; unw_context_t uc;
unw_word_t ip, sp;
unw_getcontext(&uc);
unw_init_local(&cursor, &uc);
unsigned long a[100];
int ctr = 0;
while (unw_step(&cursor) > 0) {
unw_get_reg(&cursor, UNW_REG_IP, &ip);
unw_get_reg(&cursor, UNW_REG_SP, &sp);
if (ctr >= 10) break;
a[ctr++] = ip;
}
Your approach also would work fine unless you make a call from a shared library.
You can use the addr2line
command on Linux to get the source function / line number of the corresponding PC.

- 198,619
- 38
- 280
- 391

- 61
- 1
- 1
-
"source function/line number"? What if linking is optimized for reduced code size? I will say, though, that this looks like a useful project. A pity that's there's no way to get the registers. I will definitely look into this. Do you know that it is absolutely processor independent? Just works on anything that has a C compiler? – Mawg says reinstate Monica Jan 31 '10 at 07:19
-
1Ok this comment was worth it, if only because of the mention of the helpful addr2line command! – Ogre Psalm33 Sep 23 '10 at 14:43
-
addr2line fails for relocatable code on systems with ASLR (i.e. most of what people have been using during the past decade). – Erwan Legrand Feb 08 '18 at 11:13
For Windows, CaptureStackBackTrace()
is also an option, which requires less preparation code on the user's end than StackWalk64()
does. (Also, for a similar scenario I had, CaptureStackBackTrace()
ended up working better (more reliably) than StackWalk64()
.)

- 91
- 1
- 5
There is no platform independent way to do it.
The nearest thing you can do is to run the code without optimizations. That way you can attach to the process (using the visual c++ debugger or GDB) and get a usable stack trace.

- 83,631
- 31
- 151
- 221
-
1That doesn't help me when a crash happens on an embedded computer in the field. :( – Kevin Sep 19 '08 at 21:19
-
@Kevin: Even on embedded machines, there's usually a way to get a remote debugger stub or at least a core dump. Maybe not once it's deployed to the field, though... – ephemient Jan 31 '10 at 06:49
-
if you run using gcc-glibc on your platform of choice windows/linux/mac... then backtrace() and backtrace_symbols() will work on all three platforms. Given that statement, I would use the words "there is no [portable] way to do it". – Trevor Boyd Smith Sep 09 '11 at 18:00
Solaris has the pstack command, which was also copied into Linux.

- 30,738
- 21
- 105
- 131

- 9,764
- 37
- 47
-
1
-
1also, from the description (section: restrictions) ": pstack currently works only on Linux, only on an x86 machine running 32 bit ELF binaries (64 bit not supported)" – Ciro Costa Oct 31 '15 at 19:32
You can do it by walking the stack backwards. In reality, though, it's frequently easier to add an identifier onto a call stack at the beginning of each function and pop it at the end, then just walk that printing the contents. It's a bit of a PITA, but it works well and will save you time in the end.

- 30,433
- 12
- 89
- 114
-
2
-
@Spidey On embedded systems, sometimes this is all you have - I guess this was voted down because the platform is WinXP. But without a libc that supports stack walking, basically you have to "walk" the stack. You start with the current base pointer (on x86 this is the contents of the RBP reg). That takes you to point on the stack with 1. the saved previous RBP (that's how keep the stack walk going), and 2. the call/branch return address (calling function's saved RIP reg), which tells you what the function was. Then, if you have access to the symbol table, you can look up the function address. – Ted Middleton Nov 01 '20 at 17:58
For the past few years I have been using Ian Lance Taylor's libbacktrace. It is much cleaner than the functions in the GNU C library which require exporting all the symbols. It provides more utility for the generation of backtraces than libunwind. And last but not least, it is not defeated by ASLR as are approaches requiring external tools such as addr2line
.
Libbacktrace was initially part of the GCC distribution, but it is now made available by the author as a standalone library under a BSD license:
https://github.com/ianlancetaylor/libbacktrace
At the time of writing, I would not use anything else unless I need to generate backtraces on a platform which is not supported by libbacktrace.

- 4,148
- 26
- 26