[Bug 224362] 'mutex is on list' assertion failed on pthread_mutex_lock/pthread_mutex_unlock
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Dec 15 09:36:52 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224362
Bug ID: 224362
Summary: 'mutex is on list' assertion failed on
pthread_mutex_lock/pthread_mutex_unlock
Product: Base System
Version: 9.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: threads
Assignee: freebsd-threads at FreeBSD.org
Reporter: ice.nightcrawler at gmail.com
Created attachment 188857
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188857&action=edit
Patch for libthr
I've got spontaneous core dumps on extensive mutex operations. There are many
threads and locks in my application.
And I quite sure that locking/unlocking logic is corrent - it's performing well
on other thread implementations (like NTPL on Linux).
But it is terminated by the assertion on FreeBSD after work for a long time
(from 4 up to 8 hours):
Abort trap (6) with "Fatal error 'mutex is on list'
Backtrace looks like this:
Program terminated with signal SIGABRT, Aborted.
(gdb) bt
#0 0x000000080161cd2a in thr_kill () from /lib/libc.so.7
#1 0x000000080161cc96 in raise () from /lib/libc.so.7
#2 0x000000080161b489 in abort () from /lib/libc.so.7
#3 0x000000080109e63a in ?? () from /lib/libthr.so.3
#4 0x0000000801099e66 in ?? () from /lib/libthr.so.3
#5 0x000000080242d301 in Lock (this=0x80387ad90)
(gdb) p *(struct pthread_mutex*) 0x80ff60c40
$4 = {m_lock = {m_owner = 100925, m_flags = 0, m_ceilings = {0, 0}, m_spare =
{0, 0, 0, 0}}, m_flags = 2, m_owner = 0x8038cc400, m_count = 0, m_spinloops =
0, m_yieldloops = 0, m_qe = {tqe_next = 0x0, tqe_prev = 0x0}}
"Lock" function is the last call from my application - it performs
pthread_mutex_lock() call.
In this case it just locks the mutex which was created some time before in the
same thread.
Sometimes the assertion looks like 'mutex is not on list'
It looks like for me that libthr library supports a list of acquired mutexes
for each thread. And there are checks
before locking/unlocking that get failed for unknown reason.
I've have a patch for libthr check's logic. The only effect is that some more
time is required before assertion failed again.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-threads
mailing list