xeno-test failed due to cond_destroy error

Fangsuo Wu tiger20081015 at gmail.com
Tue May 11 12:37:51 CEST 2021


Hi, the issue seems related to the gcc compiler I
used(gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux).

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}}



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
>>>
>>
>



More information about the Xenomai mailing list