glibc 的“-lmcheck” 选项和多线程
我们一直在努力解决多线程 C++ 应用程序中的一些堆损坏问题。 作为一种技术，我们尝试将 -lmcheck 添加到应用程序的库行。 这导致应用程序在相对较短的时间内崩溃并出现明显的堆损坏。
我们的应用程序确实使用了 malloc/free 和 new/delete（视情况而定）。
我们的团队之一想知道 -lmcheck 实际上是否是线程安全的，并在所有 malloc/free 调用周围放置了一个互斥锁。 崩溃消失了。
有谁知道 -lmcheck 是否应该支持多线程？ 我想知道我们是否只是误解了我们正在尝试使用的工具，从而给自己带来了不必要的担忧。
We've been trying to hunt down some heap corruption issues in our multi-threaded C++ apps. As one technique, we tried add -lmcheck to the libraries line of the application. This is causing the app to crash out with apparent heap corruption in relatively short order.
Our app does use both malloc/free and new/delete (as appropriate).
One of our team wondered if -lmcheck was in fact thread safe, and put a mutex around all malloc/free calls. The crashes went away.
Does anyone know if -lmcheck is supposed to support multi-threading? I wonder if we just mis-understand the tool we're trying to use and thereby causing ourselves unneeded worry.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，mcheck 不是线程安全的，不应该与多线程应用程序一起使用。 这样做可能会带来额外的问题，因为线程之间没有同步。 以下是几个月前 Ulrich Drepper（glibc 维护者）对此主题的回应：
No, mcheck is not thread-safe and should not be used with multi-threaded applications. Doing so can introduce additional problems since there is no synchronization between the threads. Here is the response from Ulrich Drepper (glibc maintainer) on the subject a few months ago:
在我们花时间愚弄它之前我应该检查一下。 啊，好吧。
以下是该引用来源的链接（我相信）：
http://sourceware。 org/bugzilla/show_bug.cgi?id=6547
glibc 文档缺陷：
http ://sourceware.org/bugzilla/show_bug.cgi?id=12751
已开放，以帮助避免其他人遇到此问题。
I should have checked that before we spent time fooling with it. Ahh well.
Here's the link to where that quote comes from (I believe):
http://sourceware.org/bugzilla/show_bug.cgi?id=6547
glibc documentation defect:
http://sourceware.org/bugzilla/show_bug.cgi?id=12751
has been opened to help avoid others from hitting this.
作为替代方案，我强烈推荐 valgrind - 它可以与多线程应用程序一起使用 - 尽管它模拟线程，但它实际上本身并不使用线程。
As an alternative I can highly recommend valgrind - it will work with multithreaded applications - although it emulates threads, it doesn't actually itself use threads.