Created attachment 2809 [details]
Test program to reproduce the bug

In test program there are three threads involved. The main thread creates two threads that ends up waiting for an event with a call to pthread_cond_wait. The main thread then calls pthread_cond_broadcast to wake the threads up. The main thread releases the lock, then takes the lock again. The last time the main releases the lock, pthread_mutex_unlock return error 1. Also, one of the threads is still blocked by the lock, this is not correct. 

If I comment out the line 

pthread_mutexattr_setprotocol(&mta, PTHREAD_PRIO_INHERIT);

The error disappears.

So my conclusion is that something is broken with the mutex implementation for 32-bit arm architecture.

I build everything on a host running Fedora 21.

Steps to reproduce:

Add this to local.conf

MACHINE = "qemuarm"
KERNEL_IMAGETYPE  = "zImage"
SDKMACHINE = "x86_64"
IMAGE_FEATURES += "ssh-server-dropbear"


# Then build the minimal image
bitbake core-image-minimal
# Build the SDK
bitbake core-image-minimal -c populate_sdk

Expected behavior
If everything works fine, like on x86 architectures, the output of the attached test program is

$ ./test_cond2 
Thread started 
Thread started 
thread : pthread_cond_wait: 0
Thread exit 
thread : pthread_cond_wait: 0
Thread exit 
pthread_mutex_lock return: 0 (should be 0)
Exit Counter 2 (Should be 2)
pthread_mutex_unlock return: 0 (should be 0)


If I run the test program on raspberrypi, the output will be
# ./test_cond2
Thread started
Thread started
thread : pthread_cond_wait: 0
Thread exit
pthread_mutex_lock return: 0 (should be 0)
Exit Counter 1 (Should be 2)
pthread_mutex_unlock return: 1 (should be 0)


I have tested this on a number of different architectures and two different versions of yocto. Please see the table below.

Tests on yocto fido branch (glibc 2.21) (b74ea963cefffad9fbd91d4eb9b240f6a8c86cd0)

Architecture              Bug exists?
---------------------------------------------------
qemuarm                  YES
qemuarm64                NO
qemu386                  NO


Tests on yocto master branch (glibc 2.22) (8578bc17b54da97d42b257b3c8f398ac52b91a9f)

Architecture              Bug exists?
---------------------------------------------------
qemuarm                  YES
raspberrypi              YES
qemuarm64                NO
qemu386                  NO


Tests on raspbian with kernel 4.1.7 and glibc 2.13:

Running test_cond2 on raspbian works just fine. However, if I copy the rootfs from the yocto build above (raspberrypi variant) and chroot to that directory, it doesn’t work, the bug is triggered!

I am not sure if this bug report belongs in the yocto project? Please tell me if you think it should be filed for example in the glibc project instead.