| Summary: | [glibc] pthread_mutex_unlock return 1 when PTHREAD_PRIO_INHERIT attribute is set on the mutex | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Andreas Hansson <pahansson73> | ||||
| Component: | meta-yocto | Assignee: | Juro Bystricky <juro.bystricky> | ||||
| Status: | VERIFIED NOTABUG | QA Contact: | Bogdan Alexandru Voiculescu <bogdanx.a.voiculescu> | ||||
| Severity: | major | ||||||
| Priority: | Medium+ | CC: | akuster, bogdanx.a.voiculescu, poky.bs.watcher, poky.watcher | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.1 M1 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
It looks a lot like the problem reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=18463 Both Fido and Jethro compile glibc with --enable-kernel=2.6.32 The glibc code is explicit: /* The ARM kernel before 3.14.3 may or may not support futex_atomic_cmpxchg_inatomic, depending on kernel configuration. */ #if __LINUX_KERNEL_VERSION < 0x030E03 # undef __ASSUME_FUTEX_LOCK_PI # undef __ASSUME_REQUEUE_PI # undef __ASSUME_SET_ROBUST_LIST #endif So there is no PI futex support with this configuration. I could reproduce the problem for arm. To verify my assumption, I then rebuilt qemuarm (Jethro) with the following in local.conf: OLDEST_KERNEL="3.15.1" This fixed the problem. This behaviour is by design, so it is not a bug. (Although the design reasons do not seem obvious or intuitive) Verified as not a bug since this is the design. |
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.