On Mon, Sep 26, 2011 at 12:49 PM, Philippe Gerum <[email protected]> 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. > > Nope, actually it does not, at all. It can't work in any 2.x series by > design actually, and we have the very same synchronization issue which > has just been fixed in -forge. We just happen to be lucky with timings, > likely due to the additional interactions we have with the dual kernel.
See my previous reply. We had a mechanism to make tasknames unique. > >> 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 the version I'm using (downloaded today): >> >> meeusr@meeusr-laptop:~/repo/xenomai-forge$ git log | head >> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb >> Author: Philippe Gerum <[email protected]> >> Date: Wed Sep 21 21:08:42 2011 +0200 >> >> psos: fix t_ident() with NULL name >> >> >> The configuration I did: >> ./configure --prefix=/home/meeusr/repo/xenomai-forge-install >> --enable-debug --with-core=mercury >> >> After adding the test to the makefile of the lib/psos/testsuite and >> compiling it, I start it by giving the command: >> sudo LD_LIBRARY_PATH=/home/meeusr/repo/xenomai-forge-install/lib/ gdb >> ./rtprint >> >> After some time I observe a crash: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xa7b5d870 (LWP 14707)] >> 0x00140749 in dtpvh (holder=0x80cfc7c) at >> ../../include/copperplate/private-list.h:59 >> 59 holder->prev->next = holder->next; >> (gdb) bt >> #0 0x00140749 in dtpvh (holder=0x80cfc7c) at >> ../../include/copperplate/private-list.h:59 >> #1 0x0014079c in pvlist_remove_init (holder=0x80cfc7c) at >> ../../include/copperplate/private-list.h:120 >> #2 0x00140e89 in notifier_destroy (nf=0x80cfc48) at notifier.c:195 >> #3 0x0013fb68 in threadobj_finalize (p=0x80cfbb0) at threadobj-mercury.c:161 >> #4 0x0014a3ef in __nptl_deallocate_tsd () at pthread_create.c:155 >> #5 0x0014a97c in start_thread (arg=0xa7b5d870) at pthread_create.c:307 >> #6 0x00234a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 >> (gdb) print *holder >> $1 = {next = 0x2, prev = 0x200} >> >> It looks like the holder structure is getting corrupted and this >> results in a crash while destroying a task. Please note that this is >> not the case all the time, e.g. there are already tasks destroyed >> before. >> Does anybody has a clue about the problem or how I have to proceed >> with the investigation? >> >> Thanks. >> Ronny >> _______________________________________________ >> Xenomai-help mailing list >> [email protected] >> https://mail.gna.org/listinfo/xenomai-help > > -- > Philippe. > > > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
