stack_backtracing_inside_your_program.pdf

Stack

Stack

Stack

Stack Backtracing

Backtracing

Backtracing

Backtracing Inside

Inside

Inside

Inside Your

Your

Your

Your Program

Program

Program

Program

How to use a backtrace to follow the execution path and find out what went wrong and

where.

如何使用 backtrace 函数追踪函数调用链，并且定位出错的地方以及出错原因。

If you usually work with non-trivial C sources, you may have wondered which

execution path (that is, which sequence of function calls) brought you to a certain

point in your program. Also, it would be even more useful if you could have that

而你的环境又不允许使用调试器的话，你却能利用程序本身得到一些错误的信息的

话 ， 那就再好不过了 。 幸好 glibc 提供了 backtrace 函数 ， 使得这一切变得很容易 。

Stack

Stack

Stack

Stack Frames

Frames

Frames

Frames and

栈框架和栈回溯

Before diving into the article, let's briefly go over how function calls and

parameters pass work in C. In order to prepare for the function call, parameters

are pushed on the stack in reverse order. Afterwards, the caller's return address

also is pushed on the stack and the function is called. Finally, the called function's

point, up to the main() function (to be exact, up to the libc function, which calls

main() when the process starts up).

开始本文之前 ， 让我们先简略的了解一下 C 语言的函数调用和参数传递 。 在函数调

用之前，参数按照从右向左的顺序入栈。接着，调用函数的返回地址也入栈，再接

着才调用我们想调用的函数。最后，在被调用函数的栈内分配一些空间来存储变量

（自动变量）。这种结构一般被称为栈框架。当有多个函数调用或者发生嵌套调用

时，利用系统的栈空间来建立一个栈框架链（见图 1 ）。因此，理论上在程序的任

何一个位置 ， 我们都可以回溯整个栈框架链 ， 从而到达最初的

，

main 函数也是被 libc 库调用的）。

Getting the stack backtrace with GDB (or an equivalent graphical front end)

for a program that crashed while running is straightforward: you simply issue the

bt command, which returns the list of functions called up to the point of the crash.

As this is a standard practice, we do not provide any more details here; have a

look at the GDB info page if you need specifics ( info

info

info

info gdb

gdb

gdb

gdb stack

stack

stack

stack gets you there).

当我们的程序发生错误的使用 ， 利用

GDB

回溯栈是最直截了当的办法 ： 使用

bt

命

令得到函数调用链 （ 从 libc 库到发生错误的地方 ） 。 因为这是一般的做法 ， 在这里

available for tracing what the program is doing. The first method is to disseminate

it with print and log messages in order to pinpoint the execution path. In a complex

program, this option can become cumbersome and tedious even if, with the help

of some GCC-specific macros, it can be simplified a bit. Consider, for example, a

debug macro such as .

当由于某些原因，你不能使用调试器，此时我们提供两个选择来实现追踪函数的行

为。第一，在程序中插入打印信息的语句来追踪程序的执行顺序。当然，在复杂的

程序中，这种办法会变得很笨重（尽管可以利用

一个宏：

你可以在程序中大量的插入这个宏。当不再需要时，可以关闭这个宏。

A nicer way to get a stack backtrace, however, is to use some of the specific

support functions provided by glibc. The key one is backtrace(), which navigates

the stack frames from the calling point to the beginning of the program and

provides an array of return addresses. You then can map each address to the

body of a particular function in your code by having a look at the object file with

the nm command. Or, you can do it a simpler way--use backtrace_symbols(). This

function transforms a list of return addresses, as returned by backtrace(), into a

list of strings, each containing the function name offset within the function and the

return address. The list of strings is allocated from your heap space (as if you

实际的返回地址 ） 。 这个字符串数组是通过 malloc 函数申请的 ， 所以你应该使用 fre e

函数来释放它。

If you prefer to avoid dynamic memory allocation during the

backtrace--reasonable, as the backtrace is likely to happen under faulty

conditions--you can resort to backtrace_symbols_fd(). This prints the strings

directly to the given file descriptor and does not allocate new memory for strings

storage. It is a safer choice in those cases where memory heap potentially is

corrupted.

如果栈回溯时，你想避免动态分配内存 —— 因为栈回溯是在系统不稳定的环境下

进行的 。 那么你可以使用 backtrace_symbols_fd 函数 。 backtrace_symbols_fd 函