[Bug 237195] pthread_mutex_unlock crash as unlocked mutex destroyed by signaled thread

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Apr 11 09:12:11 UTC 2019


            Bug ID: 237195
           Summary: pthread_mutex_unlock crash as unlocked mutex destroyed
                    by signaled thread
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: threads
          Assignee: threads at FreeBSD.org
          Reporter: freebsd at hurrikhan.eu
 Attachment #203579 text/plain
         mime type:

Created attachment 203579
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203579&action=edit
A simple program to reproduce the issue.

I have this program where N threads are communicating with one thread through
Some of theses messages are used to ensure synchronisation (e.g.: flush).
Each messsage contain a mutex and a condition.
When testing on FreeBSD 12.0, the program randomly crashed.
Every clue was saying the mutex was destroyed while being unlocked.
Given said program is pretty huge, I've written a small, simplified, code with
similar behaviour and it crashed the same way.

#0  0x000000080065c93a in ?? () from /lib/libthr.so.3
#1  0x0000000000401dd8 in mcv_progress (mcv=0x801c1ac00) at mutex_test.c:365
(calling pthread_mutex_unlock)
#2  0x0000000000401f46 in read_thread (arg=0x7fffffffdac0) at mutex_test.c:412
#3  0x0000000800654776 in ?? () from /lib/libthr.so.3

I suspect what happens looks something like this:

client/writer                   server/reader

1) queues message               
2) locks message.mutex         1) dequeues message
                               2) process message
3) waits for message.condition
                               3) locks message.mutex
                               4) signals message.condition
4) unlocks message.mutex       5) unlocks message.mutex
5) destroy message memory      6) somehow, still in pthread_mutex_unlock after
                                  the client got the hand back, maybe accesses
6) frees message memory           mutex content and crashes as it has been

The same program works fine under any load and parameters on several Linux
versions and OSX 10.14.4.

If this hypothesis verifies, I suppose it only affects programs rapidly
creating and destroying mutexes(+conditions?).

Please find attached the test program.

To reproduce the issue, I ctrl-C the program after 5 seconds if it didn't crash
and restart it immediately.  Four or five tries of this are usually enough.

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-threads mailing list