On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote: > On Fri, Sep 23, 2011 at 3:00 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. > >> 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. > > >> > >> 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. > > > > > > > > Ronny -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
