On 09/26/2011 11:11 PM, Philippe Gerum wrote:
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerum<r...@xenomai.org> wrote:
On Fri, 2011-09-23 at 22:23 +0200, Philippe Gerum wrote:
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum<r...@xenomai.org> wrote:
On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:
Hello
I have created some time ago a test application for the PSOS interface
of Xenomai.
This is a extensive test that stresses most of the PSOS services we
use in our application. You can find it as an attachment.
It is running fine on Xenomai 2-5-6.
Note that in the test application there is also a benchmarking part.
This is currently disabled, I will fix that later.
Now I'm investigating a switch to xenomai-forge so I tried to run the
same test on this platform.
This is a double cleanup call, due to the incorrect propagation of an
internal error detected in the task trampoline within the psos emulator.
In fact, this reveals a more general shortcoming with handling this
situation for tasks, and this may also reveal an issue with t_delete()
over the Mercury core.
I can't reproduce the issue here with your test program, but I'm sure
something is wrong in the emulator anyway, I'm just lucky with the
timings. Since you are running over the vanilla kernel and maybe x86,
you could run valgrind to check whether some memory corruption is
detected.
I'm working on this bug which will bite any emulator based on the
copperplate interface the same way. I don't see any show stopper to fix
it, but this needs some thoughts to do this properly.
Btw,
- what is your architecture?
- what is your glibc version?
Running on a PC (virtual BOX).
This is the information about the lib I use:
meeusr@meeusr-laptop:/lib$ ./libc.so.6
GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
2.11.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.3.
Compiled on a Linux>>2.6.24-27-server<< system on 2010-11-17.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
The valgrind stuff I will do later.
I can reproduce now. This is highly timing dependent.
git://git.xenomai.org/xenomai-forge.git has a general fix for this
issue. Your test code will need the following patch to work. The basic
fix is that you can't create multiple objects with the same name with
Xenomai, because we need unique names for the registry to be meaningful.
Thanks for looking into this issue.
The problem that we have is that we have a huge application and we
cannot guarantee that all tasknames are unique.
That is why I have implemented a mechanism to make a taskname unique
(I already had this in the Xenomai-2.5.6). In the force version this
could be something like:
if (name == NULL || *name == '\0')
sprintf(task->name, "t%lu", ++anon_tids);
else {
struct clusterobj *cobj =
cluster_findobj(&psos_task_table, name);
if (cobj != NULL) {
snprintf(task->name,sizeof(task->name),
"%s@%lu", name, ++anon_tids);
}
else
strncpy(task->name, name, sizeof(task->name));
task->name[sizeof(task->name) - 1] = '\0';
}
This is an example for tasks. The same could be done for
regions,semaphores and message queues. I tried it on my repo and the
task application (rtprint) runs unmodified.
The only issue I see with this approach is that when 2 tasks with an
identical name, for example TEST, are created, the second one will be
mapped to TEST@1. If a t_ident call is executed, the TID of the first
instance will be returned, which is fine. If now the first task is
deleted, the t_ident call will fail.
I have committed a general fix for this issue in the -forge repo.
Specifically, the psos emulator now accepts duplicates the way the
original API does. *_ident() will return duplicate matches by order of
registration.
If this code works as expected, then you should not have to prevent
duplicates anymore.
--
Philippe.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
