Od: "Gilles Chanteperdrix"
Komu: Petr Cervenka
Datum: 12.03.2013 13:18
Předmět: Re: [Xenomai] mutex problem
CC: "Xenomai" <[email protected]>
On 03/12/2013 10:29 AM, Petr Cervenka wrote:
Od: "Gilles Chanteperdrix" Komu: Petr Cervenka Datum: 11.03.2013
14:05 Předmět: Re: [Xenomai] mutex problem
CC: "Xenomai" <[email protected]> On 03/11/2013 11:35 AM, Petr
Cervenka wrote:
The problem with mutexes is still present. I'm really desperate
now. Does anyone know, how the mutex could "stay locked" when
every "acquire" is sooner or later followed by "release" and both
functions always return 0 (success) code? Every advice is
appreciated.
Could you provide us with a simple test case which would allow us
to reproduce the problem?
Other than that, you can try forcing the path through the kernel
for every mutex call, enable the I-pipe tracer, and trigger a trace
as soon as you detect that the mutex is not free after a release.
Sadly, I'm not able to reproduce it with simple test.
That is a rather good news.
Maybe I was not
clear, the mutex stays not locked after "release".
The thing is, Xenomai only modifies the mutex memory during the mutex
services, so, if the problem happens between the time the mutex is
released and the time the next acquistion is done, then something else
than xenomai services changes the content of the mutex memory. There are
two possible culprits:
- your application
- the kernel-side of Xenomai.
You could try recompiling without CONFIG_XENO_FASTSYNCH and see if you
still get the issue. If you still get it, the issue definitely comes
from Xenomai kernel side.
I was not able to disable CONFIG_XENO_FASTSYNCH in "xconfig". It looks like not
changeable hidden settings.
But I think it is
locked by something else because the seldom strange behavior. Example
of it follows: Imagine threads A and B A acquires lock A releases
lock B acquires lock B releases lock B tries to acquire lock, but the
mutex is already locked and the owner is A!
Also the inicialization order of threads/mutexes/... transfered the
problem to another mutex (and threads). Owner is the same thread as
before (hi priority, short time period).
This makes think about a memory issue. Is it possible to recompile your
application without xenomai and run it with valgrind?
Application was checked by usage of mtrace not long time ago. It is quite
stable, without segmentation faults.
PS: Meanwhile I found another mutex, which was deleted immediately
after creation, but commonly used later.
After I fixed it (forgotten return in initialization function between
initialization and cleanup in case of error), it survived whole night. It's too
early, but I think it could be the problem!!!
Well, yes, that could cause such issues. Could you try setting
mutex->fastlock to NULL in rt_mutex_delete?
I will try it when I have some spare time and PC for longer term test.
Petr
PS: When I enabled Xenomai debugging and I-pipe tracing (but not started) I got
some bug crash when trying to read /proc/xenomai/registry/native/mutex/...
files (in cca 50% of cases). Three such crashes and dmesg output (before crash)
are in attachment.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: errorlog.txt
URL:
<http://www.xenomai.org/pipermail/xenomai/attachments/20130313/a3879b66/attachment.txt>
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
