Re: [Xenomai-core] Deviation in Xenomai-Solo from vxWorks behaviour

[Philippe Gerum <rpm@xenomai.org>]

Niklaus Giger wrote:
> Hi
> 
> The attached program works fine under vxWorks 6.6 (powerpc).
> Running it under the current xenomai-solo (trunk) on my GNU/Debian
> x86 system it gets stuck at line 82:
> 
> Here is the output from vxWorks
>> timex tSysMain
>> assert passed at tSysMain line 66
>> assert passed at tSysMain line 67
>> assert passed at tSysMain line 70
>> assert passed at tSysMain line 71
>> assert passed at tSysMain line 74
>> assert passed at tSysMain line 75
>> assert passed at tSysMain line 77
>> assert passed at tSysMain line 78
>> assert passed at tSysMain line 79
>> assert passed at tSysMain line 80
>> assert passed at tSysMain line 82
>> assert passed at tSysMain line 83
>> tSysMain done
>> timex: time of execution = 600 +/- 2 (0%) millisecs
> whereas my gdb reports the following
>> Starting program:
>> /home/hcu/celsius/project/metaFrame/bin/BSys/mak/xeno_vx-solo/debug/tst
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0xb7c056c0 (LWP 32206)]
>> [New Thread 0xb7f02b90 (LWP 32210)]
>> [New Thread 0xb7ef1b90 (LWP 32213)]
>> assert passed at testTask line 66
>> assert passed at testTask line 67
>> assert passed at testTask line 70
>> assert passed at testTask line 71
>> assert passed at testTask line 74
>> assert passed at testTask line 75
>> assert passed at testTask line 77
>> assert passed at testTask line 78
>> assert passed at testTask line 79
>> assert passed at testTask line 80
>> ^C
>> Program received signal SIGINT, Interrupt.
>> [Switching to Thread 0xb7c056c0 (LWP 32206)]
>> 0xb7f05424 in __kernel_vsyscall ()
>> (gdb) t 3
>> [Switching to thread 3 (Thread 0xb7ef1b90 (LWP 32213))]#0  0xb7f05424 in
>> __kernel_vsyscall () (gdb) i s
>> #0  0xb7f05424 in __kernel_vsyscall ()
>> #1  0xb7e9b025 in pthread_cond_wait@domain.hid () from
>> /lib/i686/cmov/libpthread.so.0 #2  0xb7eaff2f in syncobj_pend
>> (sobj=0x83fd0d0, timeout=0x0, syns=0xb7ef12a4) at syncobj.c:152 #3 
>> 0xb7ebff80 in xsem_take (sem=0x83fd0c8, timeout=-1) at semLib.c:83 #4 
>> 0xb7ec0837 in semTake (sem_id=138399944, timeout=-1) at semLib.c:404 #5 
>> 0x08048a8d in testTask (a1=0, a2=0, a3=0, a4=0, a5=0, a6=0, a7=0, a8=0,
>> a9=0, a10=0) at ../../BSys/src/tst_main.cpp:82 #6  0xb7ec116b in
>> task_trampoline (arg=0x83fcee8) at taskLib.c:255 #7  0xb7e974c0 in
>> start_thread () from /lib/i686/cmov/libpthread.so.0 #8  0xb7ceb55e in clone
>> () from /lib/i686/cmov/libc.so.6
> It looks like under xenomai a failing semTake(aSemaphore, nWaitTime))
> erroneously decrements the counter instead of leaving .
>

You were 100% right. The patch below fixes up the sema4 count as required, thanks.

diff --git a/vxworks/semLib.c b/vxworks/semLib.c
index 3588160..62f9326 100644
--- a/vxworks/semLib.c
+++ b/vxworks/semLib.c
@@ -81,12 +81,15 @@ static STATUS xsem_take(struct wind_sem *sem, int timeout)
 		timespec = NULL;

 	ret = syncobj_pend(&sem->u.xsem.sobj, timespec, &syns);
-	if (ret == -ETIMEDOUT)
-		ret = S_objLib_OBJ_TIMEOUT;
-	else if (ret == -EINTR)
-		ret = OK;	/* Flushed. */
-	else if (ret == -EIDRM)
+	if (ret == -EIDRM)
 		return S_objLib_OBJ_DELETED;
+	if (ret) {
+		sem->u.xsem.value++;
+		if (ret == -ETIMEDOUT)
+			ret = S_objLib_OBJ_TIMEOUT;
+		else if (ret == -EINTR)
+			ret = OK;	/* Flushed. */
+	}
 done:
 	syncobj_unlock(&sem->u.xsem.sobj, &syns);

-- 
Philippe.