[Xenomai-help] sem_wait increments fault counter

[Xenomai-help] sem_wait increments fault counter

[roderik.wildenburg]

Dear Gurus,

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)
  1:            0    (Alignment)
  2:            0    (Altivec unavailable)
  3:            0    (Program check exception)
  4:            0    (Machine check exception)
  5:            0    (Unknown)
  6:            0    (Instruction breakpoint)
  7:            0    (Run mode exception)
  8:            0    (Single-step exception)
  9:            0    (Non-recoverable exception)
 10:            0    (Software emulation)
 11:            0    (Debug)
 12:            0    (SPE)
 13:            0    (Altivec assist)

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.

System: PPC Linux 2.4.25; Xenomai 2.3.5 

Thank you for your help
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] sem_wait increments fault counter

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> Dear Gurus,
> 
> 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)
>   1:            0    (Alignment)
>   2:            0    (Altivec unavailable)
>   3:            0    (Program check exception)
>   4:            0    (Machine check exception)
>   5:            0    (Unknown)
>   6:            0    (Instruction breakpoint)
>   7:            0    (Run mode exception)
>   8:            0    (Single-step exception)
>   9:            0    (Non-recoverable exception)
>  10:            0    (Software emulation)
>  11:            0    (Debug)
>  12:            0    (SPE)
>  13:            0    (Altivec assist)
> 
> 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
? 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, 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.

-- 
                                                 Gilles.

Re: [Xenomai-help] sem_wait increments fault counter

[Philippe Gerum]

On Tue, 2009-05-05 at 15:44 +0200, roderik.wildenburg@domain.hid
wrote:
> Dear Gurus,
> 
> 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)
>   1:            0    (Alignment)
>   2:            0    (Altivec unavailable)
>   3:            0    (Program check exception)
>   4:            0    (Machine check exception)
>   5:            0    (Unknown)
>   6:            0    (Instruction breakpoint)
>   7:            0    (Run mode exception)
>   8:            0    (Single-step exception)
>   9:            0    (Non-recoverable exception)
>  10:            0    (Software emulation)
>  11:            0    (Debug)
>  12:            0    (SPE)
>  13:            0    (Altivec assist)
> 
> what could be the reason for this? Is this serious?

Not necessarily on ppc. Under certain circumstances, a minor fault such
as a TLB miss may happen. Usually, 85xx is more prone to this than 6xx
though, but this does not normally affect latencies.

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

Only exceptions caught on behalf of the primary domain are reported
by /proc/xenomai/faults, so somehow, this must be a real-time thread
triggering this.

> System: PPC Linux 2.4.25; Xenomai 2.3.5 
> 
> Thank you for your help
> Roderik
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] sem_wait increments fault counter

[roderik.wildenburg]

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

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.

Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] sem_wait increments fault counter

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] sem_wait increments fault counter

[roderik.wildenburg]

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

Not exactly, I wrap all posix calls in my library (shmlib) by hand:
shm_open -> __wrap_shm_open
So, when linking shmlib with an application the wrap-options for gcc don´t need to be provided (I hope. And the linker does not complain).

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

Yes ("sem_wait itself does not return an error") .

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

No, it is not a real_time thread which causes the trap. It is just a Linux application which has been linked with my library and therefore becomes a Xenomai thread (but probably in secondary mode ?).

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

Sorry that I missed this, but the library, we are talking about, is quite old. 
So, I probably used the xenomai shared memory functions before you could tell me to use Linux shared memory services. Is the use of Xenomai shared memory functions deprecated for user space shared memory ?

Neverthelss, the problem(?) we are talking about is caused by sem_wait not by shared memory (as far as I can see).
Is the problem worth to be further investigated (at the moment I don´t have any obvious drawbacks from trap 0). If so, do you have an idea what I could do else to find out the reason for the trap 0 ?

Best regards
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] sem_wait increments fault counter

[Philippe Gerum]

On Fri, 2009-05-08 at 09:14 +0200, roderik.wildenburg@domain.hid
wrote:
> > > 
> > > 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.
> 
> Not exactly, I wrap all posix calls in my library (shmlib) by hand:
> shm_open -> __wrap_shm_open
> So, when linking shmlib with an application the wrap-options for gcc don´t need to be provided (I hope. And the linker does not complain).
> 
> >  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 ?
> > 
> 
> Yes ("sem_wait itself does not return an error") .
> 
> > > 
> > > 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.
> 
> No, it is not a real_time thread which causes the trap.

Excerpt from Xenomai's powerpc core: ksrc/arch/powerpc/hal.c:413

static inline int do_exception_event(unsigned event, unsigned domid, void *data)
{
	if (domid == RTHAL_DOMAIN_ID) {
		rthal_realtime_faults[rthal_processor_id()][event]++;

		if (rthal_trap_handler != NULL &&
		    rthal_trap_handler(event, domid, data) != 0)
			return RTHAL_EVENT_STOP;
	}

	return RTHAL_EVENT_PROPAGATE;
}

The counter reported by /proc/xenomai/faults is the one incremented
above, only if the issuing domain was Xenomai. Since only real-time
threads may live at that stage, along with Xenomai IRQ handlers, this
does imply in turn that only a real-time thread may have caused such
trap, provided your initial blame on sem_wait() is right. Really.

> It is just a Linux application which has been linked with my library
> and therefore becomes a Xenomai thread (but probably in secondary
> > mode ?).

Faults happening in secondary mode are not reported
by /proc/xenomai/faults, precisely because they do not require any
special care from Xenomai, and are simply passed down to the Linux
kernel by the interrupt pipeline.

> 
-- 
Philippe.

Re: [Xenomai-help] sem_wait increments fault counter

[roderik.wildenburg]

Thank you all for your patience in explaining me the Xenomai internals !
But obviously we can´t realy track down the problem.
Therefore I´ll try to make a short test case out of my code, which will either help you understand my problem or cut the knot in my brain ;-).

I´ll report again next week.
Have a nice weekend
Roderik

> -----Ursprüngliche Nachricht-----
> Von: Philippe Gerum [mailto:rpm@xenomai.org
> Gesendet: Freitag, 8. Mai 2009 12:36
> An: Wildenburg, Roderik RAEK3 MRA
> Cc: gilles.chanteperdrix@xenomai.org; xenomai@xenomai.org
> Betreff: Re: [Xenomai-help] sem_wait increments fault counter
> 
> On Fri, 2009-05-08 at 09:14 +0200, roderik.wildenburg@domain.hid
> wrote:
> > > > 
> > > > 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.
> > 
> > Not exactly, I wrap all posix calls in my library (shmlib) by hand:
> > shm_open -> __wrap_shm_open
> > So, when linking shmlib with an application the 
> wrap-options for gcc don´t need to be provided (I hope. And 
> the linker does not complain).
> > 
> > >  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 ?
> > > 
> > 
> > Yes ("sem_wait itself does not return an error") .
> > 
> > > > 
> > > > 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.
> > 
> > No, it is not a real_time thread which causes the trap.
> 
> Excerpt from Xenomai's powerpc core: ksrc/arch/powerpc/hal.c:413
> 
> static inline int do_exception_event(unsigned event, unsigned 
> domid, void *data)
> {
> 	if (domid == RTHAL_DOMAIN_ID) {
> 		rthal_realtime_faults[rthal_processor_id()][event]++;
> 
> 		if (rthal_trap_handler != NULL &&
> 		    rthal_trap_handler(event, domid, data) != 0)
> 			return RTHAL_EVENT_STOP;
> 	}
> 
> 	return RTHAL_EVENT_PROPAGATE;
> }
> 
> The counter reported by /proc/xenomai/faults is the one incremented
> above, only if the issuing domain was Xenomai. Since only real-time
> threads may live at that stage, along with Xenomai IRQ handlers, this
> does imply in turn that only a real-time thread may have caused such
> trap, provided your initial blame on sem_wait() is right. Really.
> 
> > It is just a Linux application which has been linked with my library
> > and therefore becomes a Xenomai thread (but probably in secondary
> > > mode ?).
> 
> Faults happening in secondary mode are not reported
> by /proc/xenomai/faults, precisely because they do not require any
> special care from Xenomai, and are simply passed down to the Linux
> kernel by the interrupt pipeline.
> 
> > 
> -- 
> Philippe.
> 
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] sem_wait increments fault counter

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
>>> 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.
> 
> Not exactly, I wrap all posix calls in my library (shmlib) by hand:
> shm_open -> __wrap_shm_open
> So, when linking shmlib with an application the wrap-options for gcc
> don´t need to be provided (I hope. And the linker does not complain).

If shmlib is a shared lib, then wrapping when compiling/linking the lib
is all that is needed. Flags do not need to be passed to the application
 using the lib. If it is a static lib, of course, things are different.

In any case, I still do not know if the calls to sem_open/sem_wait are
wrapped too ?

>>> 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.
> 
> No, it is not a real_time thread which causes the trap. It is just
> a Linux application which has been linked with my library and therefore
> becomes a Xenomai thread (but probably in secondary mode ?).

As indicated by Philippe, if the fault counter is incremented, the
Xenomai thread runs in primary mode at the time when the fault happens.

> Neverthelss, the problem(?) we are talking about is caused by
> sem_wait not by shared memory (as far as I can see).
> Is the problem worth to be further investigated (at the moment I
> don´t have any obvious drawbacks from trap 0). If so, do you have an idea what
I could do else to find out the reason for the trap 0 ?

Yes, of course, but if you use Xenomai's sem_wait, you could probably
switch to Linux' sem_wait. If you want to know why the fault happens,
then put a show_stack(NULL, NULL) at the point where the counter is
incremented.

-- 
					    Gilles.

Re: [Xenomai-help] sem_wait increments fault counter - solved

[roderik.wildenburg]

[-- Attachment #1: Type: text/plain, Size: 4899 bytes --]

When I tried to build a test for this problem, I realized that I did not use the correct shared memory size with the munmap call (and I did not check the munmap return value, blame on me). This wrong size was the reason for the increment of the trap 0 counter. So, when using the correct shared memory size the fault counter wasn´t incremented.
Astonishingly the trap 0 counter also wasn´t incremeted when the munmap size was wrong but I additionally did not (!) use a sem_wait-call !!?? Therefore I first thought the sem_wait-call is responsible for the fault counter, but obviously it wasn´t, whysoever. 

If you are interested in reproducing this behaviour, you can do so with the appended testcase.
The included makefile creates 2 processes :
- a daemon (dm) which creates shared memory and
- a client (cl) which tries to use shared memory (optionally with the use of a semaphore or without it).

Simply call "dm &" and then "cl 1". This will use the semaphore and increment the fault counter. Or call "cl 0" which will not use the semaphore and also will not increment the fault counter (cat /proc/xenomai/faults;  both calls use a wrong size parameter (0) with the munmap-call).

Sorry for having stolen your time, but the strange behavior of the semaphore use lead me on the wrong track.
Roderik


> -----Ursprüngliche Nachricht-----
> Von: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
> Gesendet: Freitag, 8. Mai 2009 17:25
> An: Wildenburg, Roderik RAEK3 MRA
> Cc: xenomai@xenomai.org
> Betreff: Re: AW: AW: [Xenomai-help] sem_wait increments fault counter
> 
> roderik.wildenburg@domain.hid wrote:
> >>> 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.
> > 
> > Not exactly, I wrap all posix calls in my library (shmlib) by hand:
> > shm_open -> __wrap_shm_open
> > So, when linking shmlib with an application the wrap-options for gcc
> > don´t need to be provided (I hope. And the linker does not 
> complain).
> 
> If shmlib is a shared lib, then wrapping when 
> compiling/linking the lib
> is all that is needed. Flags do not need to be passed to the 
> application
>  using the lib. If it is a static lib, of course, things are 
> different.
> 
> In any case, I still do not know if the calls to sem_open/sem_wait are
> wrapped too ?
> 
> >>> 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.
> > 
> > No, it is not a real_time thread which causes the trap. It is just
> > a Linux application which has been linked with my library 
> and therefore
> > becomes a Xenomai thread (but probably in secondary mode ?).
> 
> As indicated by Philippe, if the fault counter is incremented, the
> Xenomai thread runs in primary mode at the time when the 
> fault happens.
> 
> > Neverthelss, the problem(?) we are talking about is caused by
> > sem_wait not by shared memory (as far as I can see).
> > Is the problem worth to be further investigated (at the moment I
> > don´t have any obvious drawbacks from trap 0). If so, do 
> you have an idea what
> I could do else to find out the reason for the trap 0 ?
> 
> Yes, of course, but if you use Xenomai's sem_wait, you could probably
> switch to Linux' sem_wait. If you want to know why the fault happens,
> then put a show_stack(NULL, NULL) at the point where the counter is
> incremented.
> 
> -- 
> 					    Gilles.
> 
>

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

[-- Attachment #2: faulttes.zip --]
[-- Type: application/x-zip-compressed, Size: 3876 bytes --]