8552 2015-10-21 10:27:40 +0000 [glibc] pthread_mutex_unlock return 1 when PTHREAD_PRIO_INHERIT attribute is set on the mutex 2016-01-06 09:42:12 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 2.0 x86 Multiple VERIFIED NOTABUG Medium+ major 2.1 M1 1 pahansson73 juro.bystricky akuster bogdanx.a.voiculescu poky.bs.watcher poky.watcher bogdanx.a.voiculescu --- --- No (bug/feature does not impact docs) oldest_to_newest 55546 0 2809 pahansson73 2015-10-21 10:27:40 +0000 Created attachment 2809 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. 56670 1 juro.bystricky 2015-11-19 23:31:20 +0000 It looks a lot like the problem reported here: https://sourceware.org/bugzilla/show_bug.cgi?id=18463 56676 2 juro.bystricky 2015-11-20 21:45:10 +0000 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. 56679 3 juro.bystricky 2015-11-22 01:08:16 +0000 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. 56680 4 juro.bystricky 2015-11-22 02:02:59 +0000 This behaviour is by design, so it is not a bug. (Although the design reasons do not seem obvious or intuitive) 57559 5 bogdanx.a.voiculescu 2016-01-06 09:42:12 +0000 Verified as not a bug since this is the design. 2809 2015-10-21 10:27:40 +0000 2015-10-21 10:27:40 +0000 Test program to reproduce the bug test_cond2.cpp text/x-c++src 1869 pahansson73 LyoKICogQnVpbGQgbGlrZSB0aGlzIHdpdGggeW9jdG8gU0RLCiAqICMgU291cmNlIGVudmlyb25t ZW50IAogKiAgICAuIC9vcHQvcG9reS8xLjguMS9lbnZpcm9ubWVudC1zZXR1cC1hcm0xMTc2anpm c2hmLXZmcC1wb2t5LWxpbnV4LWdudWVhYmkKICogIyBCdWlsZAogKiAgICRDQyAtV2FsbCAtbHB0 aHJlYWQgLW8gdGVzdF9jb25kMiB0ZXN0X2NvbmQyLmNwcAogKi8KI2luY2x1ZGUgPHN0ZGlvLmg+ CiNpbmNsdWRlIDxwdGhyZWFkLmg+CiNpbmNsdWRlIDx1bmlzdGQuaD4KI2luY2x1ZGUgPHN0ZGJv b2wuaD4KCnN0cnVjdCBTdGF0ZQp7CiAgcHRocmVhZF9tdXRleF90KiBtdXRleDsKICBwdGhyZWFk X2NvbmRfdCogY29uZGl0aW9uOwogIGludCBleGl0Q291bnRlcjsKfTsKCnZvaWQgKiBsb2NraW5n VGhyZWFkKHZvaWQqIGRhdGEpCnsKICBTdGF0ZSogc3RhdGUgPSAoU3RhdGUqKWRhdGE7CiAgcHRo cmVhZF9tdXRleF9sb2NrKHN0YXRlLT5tdXRleCk7CiAgcHJpbnRmKCJUaHJlYWQgc3RhcnRlZCBc biIpOwogIGludCBlID0gcHRocmVhZF9jb25kX3dhaXQoc3RhdGUtPmNvbmRpdGlvbiwgc3RhdGUt Pm11dGV4KTsKICBwcmludGYoInRocmVhZCA6IHB0aHJlYWRfY29uZF93YWl0OiAlZFxuIiwgZSk7 CiAgcHJpbnRmKCJUaHJlYWQgZXhpdCBcbiIpOwogIHN0YXRlLT5leGl0Q291bnRlcisrOwogIHB0 aHJlYWRfbXV0ZXhfdW5sb2NrKHN0YXRlLT5tdXRleCk7CiAgcHRocmVhZF9leGl0KE5VTEwpOwog IHJldHVybiAwOwp9CgppbnQgbWFpbihpbnQgYXJnYywgY2hhcioqIGFyZ3YpCnsKICBwdGhyZWFk X211dGV4X3QgbXV0ZXg7CiAgcHRocmVhZF9tdXRleGF0dHJfdCBtdGE7CiAgcHRocmVhZF9tdXRl eGF0dHJfaW5pdCgmbXRhKTsKICBwdGhyZWFkX211dGV4YXR0cl9zZXR0eXBlKCZtdGEsIFBUSFJF QURfTVVURVhfRVJST1JDSEVDSyk7CiAgcHRocmVhZF9tdXRleGF0dHJfc2V0cHJvdG9jb2woJm10 YSwgUFRIUkVBRF9QUklPX0lOSEVSSVQpOwogIHB0aHJlYWRfbXV0ZXhfaW5pdCgmbXV0ZXgsICZt dGEpOwogIHB0aHJlYWRfbXV0ZXhhdHRyX2Rlc3Ryb3koJm10YSk7CgogIHB0aHJlYWRfY29uZF90 IGNvbmRpdGlvbjsKICBwdGhyZWFkX2NvbmRfaW5pdCgmY29uZGl0aW9uLCBOVUxMKTsKCiAgU3Rh dGUgc3RhdGUgPSB7ICZtdXRleCwgJmNvbmRpdGlvbiwgMCB9OwogIHB0aHJlYWRfdCB0aHJlYWQx LCB0aHJlYWQyOwogIHB0aHJlYWRfY3JlYXRlKCZ0aHJlYWQxLCBOVUxMLCBsb2NraW5nVGhyZWFk LCAodm9pZCopJnN0YXRlKTsKICBwdGhyZWFkX2NyZWF0ZSgmdGhyZWFkMiwgTlVMTCwgbG9ja2lu Z1RocmVhZCwgKHZvaWQqKSZzdGF0ZSk7CgogIHVzbGVlcCgxMDAwMDAwKTsvLyBNYWtlIHN1cmUg Ym90aCB0aHJlYWRzIGFyZSBpbiBjb25kX3dhaXQKICBwdGhyZWFkX211dGV4X2xvY2soJm11dGV4 KTsKICBwdGhyZWFkX2NvbmRfYnJvYWRjYXN0KCZjb25kaXRpb24pOyAvLyB3YWtlIGVtIHVwCiAg cHRocmVhZF9tdXRleF91bmxvY2soJm11dGV4KTsKICB1c2xlZXAoMTAwMDAwKTsgLy8gTWFrZSBz dXJlIG9uZSBvZiB0aGUgdGhyZWFkcyBnZXRzIHRoZSBsb2NrCiAgaW50IHJjID0gcHRocmVhZF9t dXRleF9sb2NrKCZtdXRleCk7CiAgcHJpbnRmKCJwdGhyZWFkX211dGV4X2xvY2sgcmV0dXJuOiAl aSAoc2hvdWxkIGJlIDApXG4iLCByYyk7CgogIHByaW50ZigiRXhpdCBDb3VudGVyICVkIChTaG91 bGQgYmUgMilcbiIsIHN0YXRlLmV4aXRDb3VudGVyKTsKICByYyA9IHB0aHJlYWRfbXV0ZXhfdW5s b2NrKCZtdXRleCk7CiAgcHJpbnRmKCJwdGhyZWFkX211dGV4X3VubG9jayByZXR1cm46ICVpIChz aG91bGQgYmUgMClcbiIsIHJjKTsKICBwdGhyZWFkX2V4aXQoTlVMTCk7Cn0K