From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <02935a30-7b67-5878-ce25-f2276aeea0a8@siemens.com> <56335a02-69dd-32ed-5c1b-9df7b1a4b760@siemens.com> From: Fangsuo Wu Date: Tue, 11 May 2021 18:37:51 +0800 Message-ID: Subject: Re: xeno-test failed due to cond_destroy error Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org Hi, the issue seems related to the gcc compiler I used=EF=BC=88gcc-linaro-arm-linux-gnueabihf-4.9-2014.08_linux=EF=BC=89. 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 =3D 153 >------->-------PTHREAD_COND_INITIALIZER; 154 155 >-------return memcmp(cond, &cond_initializer, sizeof(cond_initializer)) =3D=3D 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 =3D {0}} 2021-05-10 17:40 GMT+08:00, Fangsuo Wu : > 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 > 2 #include > 3 int main(void) > 4 { > 5 >-------pthread_cond_t cond =3D PTHREAD_COND_INITIALIZER; > 6 >-------if(pthread_cond_destroy(&cond) =3D=3D 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 : >> Jan, >> I removed the CFLAGS and LDFLAGS, with configure command: >> >> ./configure --build=3Di686-pc-linux-gnu --host=3Darm-linux-gnueabihf >> --with-core=3Dcobalt --enable-smp --enable-lazy-setsched >> --enable-debug=3Dsymbols >> >> 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 =3D PTHREAD_COND_INITIALIZER; >> 229 #if 0 >> 230 >-------pthread_cond_t cond2 =3D PTHREAD_COND_INITIALIZER; >> 231 >-------unsigned int invalmagic =3D ~0x86860505; // ~COBALT_COND_MAG= IC >> 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=3Dinstall /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 : >>> 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=3D"-march=3Darmv7-a -mfpu=3Dvfp3" >>>> LDFLAGS=3D"-march=3Darmv7-a -mfpu=3Dvfp3" --build=3Di686-pc-linux-gn= u >>>> --host=3Darm-linux-gnueabihf --with-core=3Dcobalt --enable-smp >>>> --enable-pshared >>>> make DESTDIR=3D/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=3Dsymbols" - 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 >>> >> >