（我的环境是64位Ubuntu，我的应用程序是C ++编译并与g ++链接。）
当应用程序执行除以零之类的操作或在代码中运行asm("int $3")时，以下其中一项将通过syslog记录到/var/log/kern.log和/var/log/messages：
Sep 10 18:06:47 VM kernel: [117194.123452] a.out[20288] trap divide error ip:45c59d sp:7fff65a91810 error:0 in a.out[400000+144000]
Sep 10 18:07:10 VM kernel: [117217.020833] a.out[20294] trap int3 ip:45c493 sp:7fff5cc559f0 error:0
在这两种情况下，指令指针地址指向我可以在链接时生成的.map文件中轻松查找的内容（使用“-Wl,-Map,output.map”）。
但是如果我导致seg错误，在这种情况下通过调用memcpy()并将源设置为NULL，指令指针超出范围，我不知道它应该如何映射：
Sep 10 18:06:13 VM kernel: [117160.228587] a.out[20282]: segfault at 0 ip 00007f7e79209092 sp 00007fff831faf08 error 4 in libc-2.9.so[7f7e79185000+168000]
在这个例子中，我原本期望IP在0x445e70-0x445e7f的范围内，这是我的.map文件中memcpy（）的位置。
我的问题：在这种情况下解释ip的技巧是什么？
答案 0 :(得分：3)
根据消息，它似乎在memcpy()内从libc-2.9.so崩溃，它被映射到从0x7f7e79185000开始的进程。这是预期的，因为memcpy是试图取消引用指针的函数。指令指针看起来有效，因为它在libc的范围内。如果您打算覆盖memcpy并调用自己的版本，则可能需要使用-fno-builtin-memcpy进行编译。
编辑：您可能正在静态链接libc，但根据消息，您还将libc共享库映射到您的进程内存中。在程序运行时，您应该会在/proc/ pid /maps中看到它。可能是您正在链接另一个共享库，例如libstdc ++，它依赖于libc共享库。因此，您有两个版本的memcpy，在这种情况下，它调用libc共享库版本，该版本映射到高地址。如果您不想要libc共享库，请确保静态链接所有库;使用链接行开头的-static选项。