Re: [Xenomai-help] sem_wait increments fault counter

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

roderik.wildenburg@domain.hid wrote:
>>> every time I call sem_wait a fault counter is incremented (TRAP
>>> 0). sem_wait itself does not return an error :
>>> 
>>> uc101 # cat /proc/xenomai/faults TRAP         CPU0 0:
>>> 1    (Data or instruction access)
>>> 
>>> what could be the reason for this? Is this serious? I have to add
>>> that sem_wait is called form a Linux-Prozess
>> (linked with
>>> xenomai libraries, but no xenomai thread is created) when
>> this happens.
>> 
>> Your not enough specific to get an answer. Are you talking about
>> Linux' sem_wait or about Xenomai's sem_wait ? What Xenomai library
>> are you talking about, Xenomai native skin library or Xenomai posix
>>  skin library?
> 
> It´s posix skin library, we are talking about.
> 
>> If using the Xenomai posix skin library (which would mean that you
>> use in fact Xenomai's sem_wait), the main thread is actually a
>> xenomai thread,
> 
> That´s fine/o.k. (but I didn´t know it).
> 
>> and in order to actually not create a xenomai thread, you would 
>> have to call __real_pthread_create instead of pthread_create. 
>> Otherwise, all threads are Xenomai threads.
> 
> I try to give some more information: In fact it is a library we are
> talking about (let´s call it shmlib). This library creates a shared
> memory and a (named) semaphore which should synchronise the access to
> the shared memory. This library (shmlib) is linked with Xenomai
> posix-library, so all posix-calls within shmlib should be handled by
> Xenomai.

Well, not quite. Linking is not enough. To actually use Xenomai posix
library calls, you have to pass the bunch of -Wl,--wrap options to gcc,
which you get when calling xeno-config --posix-ldflags. Is it what you
are doing.


 This shmlib is linked to different applications (build by
> different developers). To "real" Xenomai-applications  with threads
> created with pthread_create and to Linux-applications which do not
> use pthread_create (but whose main thread is a Xenomai thread, if
> linked with shmlib, as I learned just now). When such a
> Linux-application calls the shmlib synchronisation function, which in
> turn calls sem_wait(), the trap 0 counter is incremented, but no
> other error or problem occurs. If I comment out the sem_wait call in
> shmlib, the counter isn´t incremented. So my conclusion was, that
> sem_wait causes the trap 0.

If the thread using the semaphore was not a Xenomai posix skin thread,
you would not be able to call Xenomai's sem_wait, it would return -1
with errno set to EPERM.

My question may seem a little bit stupid, but are you checking the
return value of sem_wait ?

> 
> Is trap 0 explicitly generated by Xenomay in some error case or is it
> "just" a CPU error when executing an illegal instruction (but where
> should this illegal instruction/code come from ?) ?
> 
> By the way: this error also happens with Xenoami 2.4.6.

No, Xenomai has no particular reason to voluntarily generate a trap. And
this trap probably causes the calling thread to switch to secondary
mode, so this is bad news if it is a thread with actual real-time
activities. As Philippe told you, this trap may be due to some Power PC
specific behaviour.

Also, I told you that several times already, but I will tell it once
more: the Xenomai posix skin shared memory services are only useful if
you intend to share memory between a user-space real-time application
and a kernel-space real-time module. If what you want to do is simply
share memory between user-space applications, you can use Linux' shared
memory services.

-- 
                                                 Gilles.