Опция -limcheck и многопоточность в glibc

Question

Мы пытались найти некоторые проблемы с повреждением кучи в наших многопоточных приложениях C ++. В качестве одной из техник мы попытались добавить -lmcheck в строку библиотеки приложения. Это приводит к аварийному завершению работы приложения с явным повреждением кучи в относительно короткие сроки.

Наше приложение использует как malloc / free, так и new / delete (в зависимости от ситуации).

Один из наших сотрудников поинтересовался, является ли -lmcheck действительно потокобезопасным, и установил мьютекс вокруг всех вызовов malloc / free. Аварии исчезли.

Кто-нибудь знает, если -lmcheck должен поддерживать многопоточность? Интересно, неправильно ли мы понимаем инструмент, который пытаемся использовать, и тем самым вызываем у нас ненужное беспокойство?

Answer 1

Нет, mcheck не является поточно-ориентированным и не должен использоваться с многопоточными приложениями. Это может привести к дополнительным проблемам, поскольку нет синхронизации между потоками. Вот ответ Ульриха Дреппера (сопровождающего glibc) на эту тему несколько месяцев назад:

mcheck не работает для многопоточного кода. Это не может возможно сделаю. Там нет способа исправить это с технологией, лежащей в основе MУдостоверьтесь,.

Answer 2

Я должен был проверить это, прежде чем мы потратили время, чтобы дурачиться с ним. Ах, хорошо.

Вот ссылка на источник этой цитаты (я полагаю):

http://sourceware.org/bugzilla/show_bug.cgi?id=6547

дефект документации glibc:

http://sourceware.org/bugzilla/show_bug.cgi?id=12751

был открыт, чтобы помочь другим избежать этого.

Answer 3

В качестве альтернативы я настоятельно рекомендую valgrind - он будет работать с многопоточными приложениями - хотя он эмулирует потоки, он сам по себе не использует потоки.