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@@GLIBC_2.3.2 () 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.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
