如何强制中止“glibc检测到*** free():无效指针”
在Linux环境中,当出现“glibc detectors *** free(): invalidpointer”错误时,如何确定是哪行代码导致的?
有没有办法强制中止? 我记得有一个 ENV var 来控制这个?
如何在gdb中为glibc错误设置断点?
In Linux environment, when getting "glibc detected *** free(): invalid pointer" errors, how do I identify which line of code is causing it?
Is there a way to force an abort? I recall there being an ENV var to control this?
How to set a breakpoint in gdb for the glibc error?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
(gdb) b 文件名:行号
// 例如 b main.cpp:100
我的印象是它默认中止。 确保您安装了调试版本。
或者使用libdmalloc5:“替代系统的
malloc'、
realloc'、calloc'、
free'等内存管理例程,同时提供强大的调试工具可在运行时配置。 这些工具包括内存泄漏跟踪、fence-post 写入检测、文件/行号报告和一般统计记录等功能。”
将其添加到链接命令中,
当 glibc 触发中止时,gdb 应该自动返回控制权。
或者您也可以为 SIGABRT 设置信号处理程序以将堆栈跟踪转储到下面的 fd(文件描述符),mp_logfile 是一个 FILE*。
(gdb) b filename:linenumber
// e.g. b main.cpp:100
I was under the impression that it aborted by default. Make sure you have the debug version installed.
Or use libdmalloc5: "Drop in replacement for the system's
malloc',
realloc',calloc',
free' and other memory management routines while providing powerful debugging facilitiesconfigurable at runtime. These facilities include such things as memory-leak tracking, fence-post write detection, file/line number reporting, and general logging of statistics."
Add this to your link command
gdb should automatically return control when glibc triggers an abort.
Or you can set up a signal handler for SIGABRT to dump the stacktrace to a fd (file descriptor). Below, mp_logfile is a FILE*
我建议你使用 valgrind:
valgrind --tool=memcheck --leak-check=full ./a.out
I recommend you get valgrind:
valgrind --tool=memcheck --leak-check=full ./a.out
一般来说,看起来你可能需要重新编译 glibc,呃。
你没有说明你正在运行的环境,但如果你可以为 OS X 重新编译你的代码,那么它的 libc 版本有一个 free() 监听这个环境变量:
The man page for free() on OS X 有更多信息。
如果您使用的是 Linux,请尝试 Valgrind,它可以找到一些无法捕获的错误。
In general, it looks like you might have to recompile glibc, ugh.
You don't say what environment you're running on, but if you can recompile your code for OS X, then its version of libc has a free() that listens to this environment variable:
The man page for free() on OS X has more information.
If you're on Linux, then try Valgrind, it can find some impossible-to-hunt bugs.
我相信如果您将
MALLOC_CHECK_
设置为 2,glibc 在检测到“free():无效指针”错误时将调用abort()
。 请注意环境变量名称中的尾随下划线。如果
MALLOC_CHECK_
为 1,glibc 将打印“free():无效指针”(以及类似的 printfs 来处理其他错误)。 如果MALLOC_CHECK_
为0,glibc将默默地忽略此类错误并简单地返回。 如果MALLOC_CHECK_
为3,glibc将打印该消息,然后调用abort()
。 即它是一个位掩码。您还可以使用 0-3 的参数调用
mallopt(M_CHECK_ACTION, arg)
,并获得与MALLOC_CHECK_
相同的结果。由于您看到“free():无效指针”消息,我认为您一定已经在设置
MALLOC_CHECK_
或调用mallopt()
。 默认情况下 glibc 不打印这些消息。至于如何调试它,安装 SIGABRT 处理程序可能是最好的方法。 您可以在处理程序中设置断点或故意触发核心转储。
I believe if you setenv
MALLOC_CHECK_
to 2, glibc will callabort()
when it detects the "free(): invalid pointer" error. Note the trailing underscore in the name of the environment variable.If
MALLOC_CHECK_
is 1 glibc will print "free(): invalid pointer" (and similar printfs for other errors). IfMALLOC_CHECK_
is 0, glibc will silently ignore such errors and simply return. IfMALLOC_CHECK_
is 3 glibc will print the message and then callabort()
. I.e. its a bitmask.You can also call
mallopt(M_CHECK_ACTION, arg)
with an argument of 0-3, and get the same result as withMALLOC_CHECK_
.Since you're seeing the "free(): invalid pointer" message I think you must already be setting
MALLOC_CHECK_
or callingmallopt()
. By default glibc does not print those messages.As for how to debug it, installing a handler for
SIGABRT
is probably the best way to proceed. You can set a breakpoint in your handler or deliberately trigger a core dump.