Ошибка утверждения мьютекса Pthread

Непоколебимый 4 дня подряд. Я объявляю победу на этом. Ответ — «глупая ошибка пользователя» (см. комментарии выше). Мьютекс должен быть разблокирован только тем потоком, который его заблокировал. Спасибо, что терпели меня.

TLDR: убедитесь, что вы не блокируете мьютекс, который был уничтожен/не был инициализирован.

Хотя у ОП есть свой ответ, я подумал, что поделюсь своей проблемой на случай, если у кого-то еще возникнет та же проблема, что и у меня.

Обратите внимание, что утверждение находится в __pthread_mutex_lock, а не в разблокировке. Для меня это говорит о том, что большинство других людей, сталкивающихся с этой проблемой, не разблокируют мьютекс в другом потоке, чем тот, который его заблокировал; они просто блокируют мьютекс, который был уничтожен.

Для меня у меня был класс (назовем его Foo), который зарегистрировал статическую функцию обратного вызова с каким-то другим классом (назовем его Bar). Обратный вызов передавал ссылку на Foo и иногда блокировал/разблокировал мьютекс, который был членом Foo.

Эта проблема возникла после того, как экземпляр Foo был уничтожен, когда экземпляр Bar все еще использовал обратный вызов. Обратному вызову передавалась ссылка на объект, который больше не существует, и, следовательно, вызывал __pthread_mutex_lock для мусорной памяти.

Обратите внимание: я использовал std::mutex и std::lock_guard<std::mutex> из С++ 11, но, поскольку я работал в Linux, проблема была точно такой же.

Я столкнулся с той же проблемой, и Google отправил меня сюда. Проблема с моей программой заключалась в том, что в некоторых ситуациях я не инициализировал мьютекс перед его блокировкой.

Хотя утверждение в принятом ответе является законным, я думаю, что это не причина этого неудавшегося утверждения. Потому что об ошибке сообщается pthread_mutex_lock (и не разблокировка).

Также, как всегда, более вероятно, что ошибка находится в исходном коде программиста, а не в компиляторе.

Быстрый поиск в Google, который я сделал, часто обвиняет в этом неправильную оптимизацию компилятора. Подведение итогов можно найти здесь. Возможно, стоит взглянуть на вывод сборки, чтобы убедиться, что gcc создает правильный код.

Либо так, либо вам удается топать память, используемую библиотекой pthread... такие проблемы довольно сложно найти.

у меня была такая же проблема

в моем случае внутри потока я подключал vertica db к odbc, добавляя следующие настройки в /etc/odbcinst.ini, что решило мою проблему. пока не получаю исключения.

[ODBC]
Threading = 1

кредиты: hynek

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

Проблема в этом случае заключалась в том, что базовый класс создавал поток в конструкторе. Затем поток начал выполняться, и была вызвана реализация метода производных классов. К сожалению, производный класс еще не завершил построение, и мьютекс в производном классе имел неинициализированные данные в качестве владельца мьютекса. Из-за этого казалось, что он на самом деле заблокирован, когда это не так.

Решение действительно простое. Добавьте в базовый класс защищенный метод StartThread(). Это нужно вызывать в конструкторе производных классов, а не из базового класса.

Если вы используете C++ и std::unique_lock, проверьте этот ответ: https://stackoverflow.com/a/9240466/9057530

добавление Threading=0 в файл /etc/odbcinst.ini устранило эту проблему.