xeno-test failed due to cond_destroy error
Jan Kiszka
jan.kiszka at siemens.com
Wed May 12 08:51:52 CEST 2021
On 12.05.21 04:08, Fangsuo Wu wrote:
> yes, to be more accurate, the issue is found in the libc file under
> gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux/arm-linux-gnueabihf/libc/usr/include/pthread.h.
>
> The glibc is accompanied with the gcc I downloaded from
> https://releases.linaro.org/archive/14.08/components/toolchain/binaries/
>
Sounds a lot like a toolchain bug to me: Even if you only partially
initialize a struct, the remaining fields must be zeroed. Only if you do
struct.field1 = 0, struct.field2 is undefined.
Jan
> 2021-05-11 23:10 GMT+08:00, Jan Kiszka <jan.kiszka at siemens.com>:
>> On 11.05.21 12:37, Fangsuo Wu wrote:
>>> Hi, the issue seems related to the gcc compiler I
>>> used（gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux）.
>>
>> Huh, that is... well "matured".
>>
>>>
>>> I added some log and found the failure was from below code, line 155:
>>> pthread_cond_destroy
>>> -> cobalt_cond_autoinit_type:
>>> 149 static int __attribute__((cold))
>>> 150 >-------cobalt_cond_autoinit_type(const pthread_cond_t *cond)
>>> 151 {
>>> 152 >-------static const pthread_cond_t cond_initializer =
>>> 153 >------->-------PTHREAD_COND_INITIALIZER;
>>> 154
>>> 155 >-------return memcmp(cond, &cond_initializer,
>>> sizeof(cond_initializer)) == 0 ?
>>> 156 >------->-------0 : -1; //memcmp is not Zero
>>> 157 }
>>>
>>> I dumped the content of pthread_cond_t cond and cond_initializer. For
>>> the latter one, all bytes were 0, but for cond variable, only the
>>> first 44 bytes were 0, the last 4 bytes' value changed every time.
>>>
>>> I found the pthread_cond_t and PTHREAD_COND_INITIALIZER definitions
>>> in the GCC I used:
>>>
>>> #define PTHREAD_COND_INITIALIZER { { 0, 0, 0, 0, 0, (void *) 0, 0, 0}}
>>> #define __SIZEOF_PTHREAD_COND_T 48
>>>
>>> 89 typedef union
>>> 90 {
>>> 91 struct
>>> 92 {
>>> 93 int __lock;
>>> 94 unsigned int __futex;
>>> 95 __extension__ unsigned long long int __total_seq;
>>> 96 __extension__ unsigned long long int __wakeup_seq;
>>> 97 __extension__ unsigned long long int __woken_seq;
>>> 98 void *__mutex;
>>> 99 unsigned int __nwaiters;
>>> 100 unsigned int __broadcast_seq;
>>> 101 } __data;
>>> 102 char __size[__SIZEOF_PTHREAD_COND_T];
>>> 103 __extension__ long long int __align;
>>> 104 } pthread_cond_t;
>>> 105
>>>
>>> The total size of pthread_cond_t.__size is 48. But
>>> PTHREAD_COND_INITIALIZER only initializes the first 44 bytes, thus the
>>> last 4 bytes' value becomes unpredictable. The issue was gone after I
>>> made the below change:
>>>
>>> 197 //#define PTHREAD_COND_INITIALIZER { { 0, 0, 0, 0, 0, (void *) 0,
>>> 0, 0}}
>>> 198 #define PTHREAD_COND_INITIALIZER { .__size = {0}}
>>>
>>
>> Err, those types should rather come from glibc, not [lib]gcc.
>>
>> Which glibc version are you using?
>>
>> Jan
>>
>>>
>>>
>>> 2021-05-10 17:40 GMT+08:00, Fangsuo Wu <tiger20081015 at gmail.com>:
>>>> BTW, I just wrote an application which is exactly the same with
>>>> autoinit_simple_conddestroy. And it can run successfully in my board.
>>>>
>>>> 1 #include <stdio.h>
>>>> 2 #include <pthread.h>
>>>> 3 int main(void)
>>>> 4 {
>>>> 5 >-------pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
>>>> 6 >-------if(pthread_cond_destroy(&cond) == 0)
>>>> 7 >------->-------printf("suc!\n");
>>>> 8 >-------else
>>>> 9 >------->-------printf("err!\n");
>>>> 10 }
>>>>
>>>> sh-4.4# ./main
>>>> suc!
>>>>
>>>>
>>>> 2021-05-10 17:28 GMT+08:00, Fangsuo Wu <tiger20081015 at gmail.com>:
>>>>> Jan,
>>>>> I removed the CFLAGS and LDFLAGS, with configure command:
>>>>>
>>>>> ./configure --build=i686-pc-linux-gnu --host=arm-linux-gnueabihf
>>>>> --with-core=cobalt --enable-smp --enable-lazy-setsched
>>>>> --enable-debug=symbols
>>>>>
>>>>> But the issue still remains. I changed the failed test case as below,
>>>>> the issue still exists.
>>>>>
>>>>> 226 static void autoinit_simple_conddestroy(void)
>>>>> 227 {
>>>>> 228 >-------pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
>>>>> 229 #if 0
>>>>> 230 >-------pthread_cond_t cond2 = PTHREAD_COND_INITIALIZER;
>>>>> 231 >-------unsigned int invalmagic = ~0x86860505; //
>>>>> ~COBALT_COND_MAGIC
>>>>> 232
>>>>> 233 >-------memcpy((char *)&cond2 + sizeof(cond2) - sizeof(invalmagic),
>>>>> 234 >------->-------&invalmagic, sizeof(invalmagic));
>>>>> 235
>>>>> 236 >-------smokey_trace("%s", __func__);
>>>>> 237 #endif
>>>>> 238 >-------check("cond_destroy", cond_destroy(&cond), 0);
>>>>> 239 //>-----check("cond_destroy invalid", cond_destroy(&cond2),
>>>>> -EINVAL);
>>>>> 240 }
>>>>>
>>>>> I'll try QEMU later to see if the issue also exits in QEMU.
>>>>>
>>>>> BTW, I saw some below warnings in compiling, do they have any
>>>>> relationship with the issue?
>>>>> /bin/bash ../../../libtool --mode=install /usr/bin/install -c
>>>>> smokey_net_server '/home/data/nfs_test//usr/xenomai/bin'
>>>>> libtool: warning: '../../../lib/cobalt/libcobalt.la' has not been
>>>>> installed in '/usr/xenomai/lib'
>>>>> libtool: warning: '../../../lib/cobalt/libmodechk.la' has not been
>>>>> installed in '/usr/xenomai/lib'
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2021-05-10 15:35 GMT+08:00, Jan Kiszka <jan.kiszka at siemens.com>:
>>>>>> On 10.05.21 09:20, Fangsuo Wu wrote:
>>>>>>> Jan,
>>>>>>> Thanks for your reply. The environment I used is listed below. BTW, I
>>>>>>> can run latency test successfully.
>>>>>>>
>>>>>>> 1. The revision of Xenomai: xenomai-3.1.tar.bz2
>>>>>>> 2. Soc: dual ARM cortex A7
>>>>>>> 3. How I built application libraries:
>>>>>>> ./configure CFLAGS="-march=armv7-a -mfpu=vfp3"
>>>>>>> LDFLAGS="-march=armv7-a -mfpu=vfp3" --build=i686-pc-linux-gnu
>>>>>>> --host=arm-linux-gnueabihf --with-core=cobalt --enable-smp
>>>>>>> --enable-pshared
>>>>>>> make DESTDIR=/home/data/nfs_test/ install
>>>>>>> 4. The kernel I used is 4.19 so I applied
>>>>>>> ipipe-core-4.19.55-arm-5.patch, and manually enabled
>>>>>>> CONFIG_IPIPE_ARM_KUSER_TSC. The full config file is:
>>>>>>>
>>>>>>
>>>>>> OK - our qemu-armhf target [1] is multicore A7 as well. Do you see the
>>>>>> problem in QEMU, too? Do any of the extra CFLAGS or LDFLAGS you pass
>>>>>> play a role here? We compile in CI only with "--enable-smp
>>>>>> --enable-lazy-setsched --enable-debug=symbols" - maybe
>>>>>> "--enable-pshared"...
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>> [1] https://source.denx.de/Xenomai/xenomai-images/-/jobs/265962#L387
>>>>>>
>>>>>> --
>>>>>> Siemens AG, T RDA IOT
>>>>>> Corporate Competence Center Embedded Linux
>>>>>>
>>>>>
>>>>
>>
>> --
>> Siemens AG, T RDA IOT
>> Corporate Competence Center Embedded Linux
>>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
More information about the Xenomai
mailing list