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

Question

Я сталкиваюсь со следующей ошибкой в непредсказуемое время в коммуникационном приложении на базе Linux (arm):

pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

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

Заранее благодарю.

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

[ODBC]
Threading = 1

кредиты для : хайнек

Answer 6

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

Answer 7

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

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

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