在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈。
[cpp] view plain copy print?
int backtrace(void **buffer,int size)
该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小
在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址
注意:某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架删除框架指针也会导致无法正确解析堆栈内容
[cpp] view plain copy print?
char ** backtrace_symbols (void *const *buffer, int size)
backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的指针数组,size是该数组中的元素个数(backtrace的返回值)
函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名，函数的偏移地址,和实际的返回地址
现在,只有使用ELF二进制格式的程序才能获取函数名称和偏移地址.在其他系统,只有16进制的返回地址能被获取.另外,你可能需要传递相应的符号给链接器,以能支持函数名功能(比如,在使用GNU ld链接器的系统中,你需要传递(-rdynamic)， -rdynamic可用来通知链接器将所有符号添加到动态符号表中，如果你的链接器支持-rdynamic的话，建议将其加上！)
该函数的返回值是通过malloc函数申请的空间,因此调用者必须使用free函数来释放指针.
注意:如果不能为字符串获取足够的空间函数的返回值将会为NULL
[cpp] view plain copy print?
void backtrace_symbols_fd (void *const *buffer, int size, int fd)
backtrace_symbols_fd与backtrace_symbols 函数具有相同的功能,不同的是它不会给调用者返回字符串数组,而是将结果写入文件描述符为fd的文件中,每个函数对应一行.它不需要调用malloc函数,因此适用于有可能调用该函数会失败的情况
下面是glibc中的实例（稍有修改）：
[cpp] view plain copy print?
#include <execinfo.h>
#include <stdio.h>
#include <stdlib.h>
/* Obtain a backtrace and print it to @code{stdout}. */
void print_trace (void)
{
void *array[10]
size_t size
char **strings
size_t i
size = backtrace (array, 10)
strings = backtrace_symbols (array, size)
if (NULL == strings)
{
perror("backtrace_synbols")
Exit(EXIT_FAILURE)
}
printf ("Obtained %zd stack frames.\n", size)
for (i = 0i <sizei++)
printf ("%s\n", strings[i])
free (strings)
strings = NULL
}
/* A dummy function to make the backtrace more interesting. */
void dummy_function (void)
{
print_trace ()
}
int main (int argc, char *argv[])
{
dummy_function ()
return 0
}
输出如下：
[cpp] view plain copy print?
Obtained 4 stack frames.
./execinfo() [0x80484dd]
./execinfo() [0x8048549]
./execinfo() [0x8048556]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x70a113]
我们还可以利用这backtrace来定位段错误位置。
通常情况系，程序发生段错误时系统会发送SIGSEGV信号给程序，缺省处理是退出函数。我们可以使用 signal(SIGSEGV, &your_function)函数来接管SIGSEGV信号的处理，程序在发生段错误后，自动调用我们准备好的函数，从而在那个函数里来获取当前函数调用栈。
举例如下：
[cpp] view plain copy print?
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <execinfo.h>
#include <signal.h>
void dump(int signo)
{
void *buffer[30] = {0}
size_t size
char **strings = NULL
size_t i = 0
size = backtrace(buffer, 30)
fprintf(stdout, "Obtained %zd stack frames.nm\n", size)
strings = backtrace_symbols(buffer, size)
if (strings == NULL)
{
perror("backtrace_symbols.")
exit(EXIT_FAILURE)
}
for (i = 0i <sizei++)
{
fprintf(stdout, "%s\n", strings[i])
}
free(strings)
strings = NULL
exit(0)
}
void func_c()
{
*((volatile char *)0x0) = 0x9999
}
void func_b()
{
func_c()
}
void func_a()
{
func_b()
}
int main(int argc, const char *argv[])
{
if (signal(SIGSEGV, dump) == SIG_ERR)
perror("can't catch SIGSEGV")
func_a()
return 0
}
编译程序：
gcc -g -rdynamic test.c -o test./test
输出如下：
[cpp] view plain copy print?
Obtained6stackframes.nm
./backstrace_debug(dump+0x45)[0x80487c9]
[0x468400]
./backstrace_debug(func_b+0x8)[0x804888c]
./backstrace_debug(func_a+0x8)[0x8048896]
./backstrace_debug(main+0x33)[0x80488cb]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x129113]
（这里有个疑问： 多次运行的结果是/lib/i368-Linux-gnu/libc.so.6和[0x468400]的返回地址是变化的，但不变的是后三位， 不知道为什么）
接着：
objdump -d test >test.s
在test.s中搜索804888c如下：
[cpp] view plain copy print?
8048884 <func_b>:
8048884:55 push %ebp
8048885:89 e5mov %esp, %ebp
8048887:e8 eb ff ff ff call 8048877 <func_c>
804888c:5dpop %ebp
804888d:c3ret
其中80488c时调用（call 8048877）C函数后的地址，虽然并没有直接定位到C函数，通过汇编代码， 基本可以推出是C函数出问题了（pop指令不会导致段错误的）。
我们也可以通过addr2line来查看
[cpp] view plain copy print?
addr2line 0x804888c -e backstrace_debug -f
输出：
[cpp] view plain copy print?
func_b
/home/astrol/c/backstrace_debug.c:57
以下是简单的backtrace原理实现：
【缓冲区溢出的处理】你屋子里的门和窗户越少，入侵者进入的方式就越少……
由于缓冲区溢出是一个编程问题，所以只能通过修复被破坏的程序的代码而解决问题。如果你没有源代码，从上面“堆栈溢出攻击”的原理可以看出，要防止此类攻击，我们可以：
① 开放程序时仔细检查溢出情况，不允许数据溢出缓冲区。由于编程和编程语言的原因，这非常困难，而且不适合大量已经在使用的程序；
② 使用检查堆栈溢出的编译器或者在程序中加入某些记号，以便程序运行时确认禁止黑客有意造成的溢出。问题是无法针对已有程序，对新程序来讲，需要修改编译器；
③ 经常检查你的 *** 作系统和应用程序提供商的站点，一旦发现他们提供的补丁程序，就马上下载并且应用在系统上，这是最好的方法。但是系统管理员总要比攻击者慢 一步，如果这个有问题的软件是可选的，甚至是临时的，把它从你的系统中删除。举另外一个例 子，你屋子里的门和窗户越少，入侵者进入的方式就越少。
----------------------------------------------------------------------------------------------------------------------------------------
char buf[3]
memset(buf,0x55,10)
这个程序就存在溢出
对数据块的访问超出该数据块的地址范围
===================================================================================
【一个检测工具】
Valgrind 是一款 Linux下（支持 x86、x86_64和ppc32）程序的内存调试工具，它可以对编译后的二进制程序进行内存使用监测（C语言中的 malloc 和 free，以及 C++ 中的 new 和 delete），找出内存泄漏问题。
Valgrind 中包含的 Memcheck 工具可以检查以下的程序错误：
使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 （Reading/writing memory after it has been free’d）
使用超过 malloc 分配的内存空间（Reading/writing off the end of malloc’d blocks）
对堆栈的非法访问（Reading/writing inappropriate areas on the stack）
申请的空间是否有释放（Memory leaks – where pointers to malloc’d blocks are lost forever）
malloc/free/new/delete 申请和释放内存的匹配（Mismatched use of malloc/new/new [] vs free/delete/delete []）
src 和 dst 的重叠（Overlapping src and dst pointers in memcpy() and related functions）
重复 free
① 编译安装 Valgrind：
# wget http://valgrind.org/downloads/valgrind-3.4.1.tar.bz2
# tar xvf valgrind-3.4.1.tar.bz2
# cd valgrind-3.4.1/
# ./configure
…………
Primary build target: X86_LINUX
Secondary build target:
Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.5.supp
# make
# make install
# whereis valgrind
valgrind:
/usr/bin/valgrind
/usr/lib/valgrind
/usr/local/bin/valgrind
/usr/local/lib/valgrind
/usr/include/valgrind
/usr/share/man/man1/valgrind.1.gz
运行程序
使用示例：对“ls”程序进程检查，返回结果中的“definitely lost: 0 bytes in 0 blocks.”表示没有内存泄漏。
# /usr/local/bin/valgrind --tool=memcheck --leak-check=full ls /
==29801== Memcheck, a memory error detector.
==29801== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==29801== Using LibVEX rev 1884, a library for dynamic binary translation.
==29801== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==29801== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==29801== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==29801== For more details, rerun with: -v
==29801==
bin etc lost+found mnt proc selinuxsys usr
boot home media net root smokeping tftpboot var
dev lib miscopt sbin srvtmp
==29801==
==29801== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 21 from 1)
==29801== malloc/free: in use at exit: 14,744 bytes in 32 blocks.
==29801== malloc/free: 162 allocs, 130 frees, 33,758 bytes allocated.
==29801== For counts of detected errors, rerun with: -v
==29801== searching for pointers to 32 not-freed blocks.
==29801== checked 139,012 bytes.
==29801==
==29801== LEAK SUMMARY:
==29801==definitely lost: 0 bytes in 0 blocks.
==29801== possibly lost: 0 bytes in 0 blocks.
==29801==still reachable: 14,744 bytes in 32 blocks.
==29801== suppressed: 0 bytes in 0 blocks.
==29801== Reachable blocks (those to which a pointer was found) are not shown.
==29801== To see them, rerun with: --leak-check=full --show-reachable=yes
----------------------------------------------------------------------------------------------------------------------------------------
# /usr/local/bin/valgrind --tool=memcheck --leak-check=full ps /
==29898== Memcheck, a memory error detector.
==29898== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==29898== Using LibVEX rev 1884, a library for dynamic binary translation.
==29898== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==29898== Using valgrind-3.4.1, a dynamic binary instrumentation framework.
==29898== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==29898== For more details, rerun with: -v
==29898==
ERROR: Garbage option.
********* simple selection ********* ********* selection by list *********
-A all processes -C by command name
-N negate selection -G by real group ID (supports names)
-a all w/ tty except session leaders -U by real user ID (supports names)
-d all except session leaders -g by session OR by effective group name
-e all processes -p by process ID
T all processes on this terminal -s processes in the sessions given
a all w/ tty, including other users -t by tty
g OBSOLETE -- DO NOT USE -u by effective user ID (supports names)
r only running processes U processes for specified users
x processes w/o controlling ttys t by tty
*********** output format ********** *********** long options ***********
-o,o user-defined -f full--Group --User --pid --cols --ppid
-j,j job control s signal --group --user --sid --rows --info
-O,O preloaded -o v virtual memory --cumulative --format --deselect
-l,l long u user-oriented --sort --tty --forest --version
-F extra fullX registers --heading --no-heading --context
********* misc options *********
-V,V show version L list format codes f ASCII art forest
-m,m,-L,-T,H threads S children in sum-y change -l format
-M,Z security data c true command name -c scheduling class
-w,w wide output n numeric WCHAN,UID -H process hierarchy
==29898==
==29898== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 1)
==29898== malloc/free: in use at exit: 16 bytes in 2 blocks.
==29898== malloc/free: 20 allocs, 18 frees, 2,344 bytes allocated.
==29898== For counts of detected errors, rerun with: -v
==29898== searching for pointers to 2 not-freed blocks.
==29898== checked 263,972 bytes.
==29898==
==29898== 8 bytes in 1 blocks are definitely lost in loss record 2 of 2
==29898==at 0x4005A88: malloc (vg_replace_malloc.c:207)
==29898==by 0xBFF6DF: strdup (in /lib/libc-2.5.so)
==29898==by 0x804A464: (within /bin/ps)
==29898==by 0x804A802: (within /bin/ps)
==29898==by 0x804964D: (within /bin/ps)
==29898==by 0xBA5E8B: (below main) (in /lib/libc-2.5.so)
==29898==
==29898== LEAK SUMMARY:
==29898==definitely lost: 8 bytes in 1 blocks.
==29898== possibly lost: 0 bytes in 0 blocks.
==29898==still reachable: 8 bytes in 1 blocks.
==29898== suppressed: 0 bytes in 0 blocks.
==29898== Reachable blocks (those to which a pointer was found) are not shown.
==29898== To see them, rerun with: --leak-check=full --show-reachable=yes
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）