[Bug nptl/17514] New: Assert failure unlocking ERRORCHECK mutex after timedlock (related to lock elision)

[Bug nptl/17514] New: Assert failure unlocking ERRORCHECK mutex after timedlock (related to lock elision)

[juhapi+sw at lubenter dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=17514

            Bug ID: 17514
           Summary: Assert failure unlocking ERRORCHECK mutex after
                    timedlock (related to lock elision)
           Product: glibc
           Version: 2.20
            Status: NEW
          Severity: critical
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: juhapi+sw at lubenter dot net
                CC: drepper.fsp at gmail dot com

I noticed an application crashing in pthread_mutex_unlock(), and simplified the
problematic call sequence to the one seen in this simple program:

#include <pthread.h>

int main()
{
  pthread_mutex_t m;
  pthread_mutexattr_t attr;
  struct timespec abs_time = {0};

  pthread_mutexattr_init(&attr);
  pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);

  pthread_mutex_init(&m, &attr);
  pthread_mutex_timedlock(&m, &abs_time);
  pthread_mutex_unlock(&m);              // <= assert fails here

  return 0;
}

If the mutex is of default type, or if locking is done with
pthread_mutex_lock(), the assert doesn't fail. Also I believe the problem only
occurs when lock elision is available. But the combination of ERRORCHECK mutex,
pthread_mutex_timelock() and lock elision seems problematic.

The bactrace I get is below. The assert fails because m.__data.__kind is 258
(=0x102, with the elision bit 0x100 set) but the pthread_mutex_unlock() expects
it to be 2. I don't know if the problem is in pthread_mutex_timedlock() that
sets the elision bit, or in pthread_mutex_unlock() that doesn't allow the bit
to be set.

(gdb) bt
#0  0x00007fe5eebb6a07 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007fe5eebb7dda in __GI_abort () at abort.c:89
#2  0x00007fe5eebaf8bd in __assert_fail_base (fmt=0x7fe5eecebab8 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x7fe5eef38530 "type ==
PTHREAD_MUTEX_ERRORCHECK_NP", file=file@entry=0x7fe5eef38518
"pthread_mutex_unlock.c", line=line@entry=87, 
    function=function@entry=0x7fe5eef38560 <__PRETTY_FUNCTION__.7552>
"__pthread_mutex_unlock_usercnt") at assert.c:92
#3  0x00007fe5eebaf972 in __GI___assert_fail
(assertion=assertion@entry=0x7fe5eef38530 "type ==
PTHREAD_MUTEX_ERRORCHECK_NP", 
    file=file@entry=0x7fe5eef38518 "pthread_mutex_unlock.c",
line=line@entry=87, function=function@entry=0x7fe5eef38560
<__PRETTY_FUNCTION__.7552> "__pthread_mutex_unlock_usercnt")
    at assert.c:101
#4  0x00007fe5eef30efe in __pthread_mutex_unlock_usercnt (mutex=<optimized
out>, decr=<optimized out>) at pthread_mutex_unlock.c:87
#5  0x000000000040085c in main () at glibc_bug_mutextest.c:14

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17514] Assert failure unlocking ERRORCHECK mutex after timedlock (related to lock elision)

[milinevskyy at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17514

Dmytro Milinevskyy <milinevskyy at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |milinevskyy at gmail dot com

--- Comment #1 from Dmytro Milinevskyy <milinevskyy at gmail dot com> ---
Seems like the bug is not present if mutex is set as robust.

-- 
You are receiving this mail because:
You are on the CC list for the bug.