* [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
@ 2011-09-22 20:15 Ronny Meeus
2011-09-23 13:00 ` Philippe Gerum
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Ronny Meeus @ 2011-09-22 20:15 UTC (permalink / raw)
To: xenomai-help
[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]
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 the version I'm using (downloaded today):
meeusr@domain.hid$ git log | head
commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
Author: Philippe Gerum <rpm@xenomai.org>
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
[-- Attachment #2: rtprint.c --]
[-- Type: text/x-csrc, Size: 19610 bytes --]
#include <psos/psos.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <stdarg.h>
#include <string.h>
#include <copperplate/init.h>
/*************************************************************************/
char buffer[10000];
char *p = buffer;
static void my_printf_flush(void)
{
printf("%s",buffer);
p = buffer;
}
static void my_printf(const char *fmt,...)
{
va_list arg;
va_start (arg, fmt);
p += vsprintf(p,fmt,arg);
va_end (arg);
if ((p-buffer)>8000)
my_printf_flush();
}
/*************************************************************************/
static void check_inner(const char *fn, int line, const char *msg,
int status, int expected)
{
return;
if (status == expected)
return;
my_printf("FAILED %s:%d: %s returned %d instead of %d - %s\n",
fn, line, msg, status, expected, strerror(-status));
my_printf_flush();
while (1)
tm_wkafter(100);
}
#define check(msg, status, expected) check_inner(__FUNCTION__,__LINE__,msg,status,expected)
/*************************************************************************/
static unsigned long error = 0;
static unsigned long ev_error = 0;
typedef struct
{
unsigned long long start;
unsigned long long stop;
} timestamp_info;
static void benchmark_start_test(timestamp_info *ts)
{
ts->start = 0;
}
/*
* static void benchmark_stop_test(timestamp_info *ts)
{
ts->stop = 0;
}
*/
static void benchmark_stop_and_report_test(timestamp_info *ts,unsigned long count,
const char *fmt,...)
{
unsigned long long delta;
va_list arg;
char output[128];
memset(output,0,sizeof(output));
ts->stop =0;
delta = ts->stop - ts->start;
va_start (arg, fmt);
vsprintf(output,fmt,arg);
va_end (arg);
if (!count) count = 1;
my_printf("[err=%ld,ev_err=%ld] %s took %lld ns (%lld usec). %lld ns / cycle\n",
error,ev_error,output,delta,delta/1000,delta/count);
}
/*************************************************************************/
static void test_taskregisters_body(u_long expected_register_value,
u_long b,u_long c,u_long d)
{
unsigned long reg = 0;
check("t_getreg",t_getreg(0UL,0UL,®),0);
check("reg",reg,expected_register_value);
t_delete(0);
}
static void test_taskregisters(void)
{
unsigned long tid;
unsigned long args[4] = {0,0,0,0};
unsigned long reg_value = 0;
my_printf("%s\n",__FUNCTION__);
check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
check("t_setreg",t_setreg(tid,0UL,100UL),0);
check("t_getreg",t_getreg(tid,0UL,®_value),0);
check("reg_value",reg_value,100);
args[0] = 100;
check("t_start",t_start(tid,0,test_taskregisters_body,args),0);
}
/*************************************************************************/
static unsigned long counter;
static int suspendmyself = 0;
static void test_tasksuspend_body(u_long destroy,u_long b,u_long c,u_long d)
{
while (1)
{
counter++;
tm_wkafter(1);
if (suspendmyself)
t_suspend(0);
}
}
static void test_tasksuspend(void)
{
unsigned long tid;
unsigned long args[4] = {0,0,0,0};
unsigned long counter_keep;
my_printf("%s\n",__FUNCTION__);
suspendmyself = 0;
check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_tasksuspend_body,args),0);
counter = 0;
tm_wkafter(5);
t_suspend(tid);
counter_keep = counter;
tm_wkafter(5);
check("suspend count",counter,counter_keep);
t_resume(tid);
tm_wkafter(5);
if (counter == counter_keep)
check("resume count",1,0);
suspendmyself = 1;
tm_wkafter(5);
counter_keep = counter;
tm_wkafter(5);
check("suspend count",counter,counter_keep);
t_delete(tid);
}
/*************************************************************************/
static void test_taskcreation_body(u_long destroy,u_long b,u_long c,u_long d)
{
check("b",b,200);
check("c",c,300);
check("d",d,400);
if (destroy)
t_delete(0);
while (1)
tm_wkafter(1000);
}
static void test_taskcreation_body2(u_long a,u_long b,u_long c,u_long d)
{
check("a",a,100);
check("b",b,200);
check("c",c,300);
check("d",d,400);
t_delete(0);
}
static void create_and_start_task(unsigned long *tid)
{
unsigned long local_args[4] = {0,200,300,400};
check("t_create low prio",t_create ("TEST",2,4000,0,T_LOCAL,tid),0);
check("t_start low prio",t_start(*tid,T_PREEMPT|T_TSLICE,test_taskcreation_body,local_args),0);
}
static void test_taskcreation(void)
{
unsigned long tid,tid2;
unsigned long tids[10];
unsigned long args[4] = {100,200,300,400};
int i;
my_printf("%s\n",__FUNCTION__);
check("t_create",t_create("TEST111",2,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_taskcreation_body2,args),0);
for (i=1;i<2;i++)
{
check("t_create",t_create("TEST",(unsigned long)i,16000,16000,0,&tid),0);
check("t_start",t_start(tid,T_PREEMPT| T_TSLICE | T_NOASR,test_taskcreation_body2,args),0);
}
args[0] = 1;
check("t_create",t_create("1TEST",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_taskcreation_body,args),0);
args[0] = 0;
check("t_create",t_create("2TEST",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_taskcreation_body,args),0);
check("t_ident",t_ident("2TEST",0,&tid2),0);
check("tid",tid,tid2);
check("t_delete",t_delete(tid),0);
/* Create multiple tasks with the same name */
args[0] = 0;
for (i=0;i<1;i++)
{
check("t_create loop",t_create ("TTTT",64,100000,0,0,&tids[i]),0);
check("t_start loop",t_start(tids[i],T_PREEMPT,test_taskcreation_body,args),0);
}
check("t_ident loop",t_ident("TTTT",0,&tid2),0);
check("tid check",tid2,tids[0]);
for (i=0;i<1;i++)
{
check("t_delete loop",t_delete(tids[i]),0);
}
args[0] = 0;
for (i=0;i<1;i++)
{
check("t_create loop2",t_create ("TEST",64,100000,0,0,&tid),0);
check("t_delete loop2",t_delete(tid),0);
my_printf("t_create + t_delete %d\r",i);
}
my_printf("\n");
args[0] = 0;
for (i=0;i<500;i++)
{
check("t_create loop3",t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
check("t_start loop3",t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
check("t_delete loop3",t_delete(tid),0);
my_printf("t_create + t_start + t_delete %d\r",i);
}
my_printf("\n");
args[0] = 0;
for (i=0;i<1;i++)
{
create_and_start_task(&tids[i]);
}
tm_wkafter(10);
for (i=0;i<1;i++)
{
check("t_delete loop3",t_delete(tids[i]),0);
}
my_printf("\n");
}
/*************************************************************************/
static void test_basicevents(void)
{
unsigned long mask,ev_rcvd;
int i;
mask = 1;
for (i=0;i<32;i++)
{
check("ev_send 1",ev_send(0,mask),0);
check("ev_receive 1",ev_receive(mask,EV_ALL|EV_NOWAIT,0,&ev_rcvd),0);
check("received events 1",mask,ev_rcvd);
mask <<= 1;
}
mask = 1;
for (i=0;i<32;i++)
{
check("ev_send many",ev_send(0,mask),0);
check("ev_receive many",ev_receive(mask,EV_ALL|EV_NOWAIT,0,&ev_rcvd),0);
check("received events many",mask,ev_rcvd);
mask = (mask << 1) | 1;
}
mask = 1;
for (i=0;i<32;i++)
{
check("ev_send once",ev_send(0,mask),0);
mask <<= 1;
}
mask = 0xffffffff;
ev_rcvd = 0;
check("ev_receive once",ev_receive(mask,EV_ALL|EV_NOWAIT,0,&ev_rcvd),0);
check("received events once",0xffffffff,ev_rcvd);
}
static void test_events_body(u_long tid,u_long b,u_long c,u_long d)
{
test_basicevents();
ev_send(tid,1);
t_delete(0);
}
static void test_events(void)
{
unsigned long tid;
unsigned long args[4] = {0,0,0,0};
unsigned long ev_rcvd;
my_printf("%s\n",__FUNCTION__);
test_basicevents();
t_ident(0,0,&args[0]);
check("t_create",t_create("TEST",2,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_events_body,args),0);
ev_receive(1,EV_ALL|EV_WAIT,0,&ev_rcvd);
}
/*************************************************************************/
static void test_queuecreation(void)
{
unsigned long qid,qid2;
unsigned long qids[50];
int i;
my_printf("%s\n",__FUNCTION__);
check("q_create",q_create("TTTT",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
check("q_ident",q_ident("TTTT",0,&qid2),0);
check("compate qids",qid,qid2);
check("q_delete",q_delete(qid),0);
for (i=0;i<100;i++)
{
check("q_create",q_create("TTTS",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
check("q_delete",q_delete(qid),0);
}
for (i=0;i<50;i++)
check("q_create",q_create("TTTU",0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
for (i=0;i<50;i++)
check("q_delete",q_delete(qids[i]),0);
}
/*************************************************************************/
static void test_queue(void)
{
unsigned long qid;
unsigned long mesg[4] = {0,1,2,3};
unsigned long recv_msg[4];
int i;
char testCaseName[32];
timestamp_info timeInfo;
my_printf("%s\n",__FUNCTION__);
check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
check("q_send",q_send(qid,mesg),0);
check("q_receive",q_receive(qid,Q_NOWAIT,0,recv_msg),0);
check("q_receive TO",q_receive(qid,Q_WAIT,50,recv_msg),ERR_TIMEOUT);
for (i=0;i<1000;i++)
{
sprintf(testCaseName,"q_send LOOP %d",i);
mesg[3] = (unsigned long)i;
check(testCaseName,q_send(qid,mesg),0);
}
i=0;
while (q_receive(qid,Q_NOWAIT,0,recv_msg) == 0)
{
check("MSG 0",recv_msg[0],mesg[0]);
check("MSG 1",recv_msg[1],mesg[1]);
check("MSG 2",recv_msg[2],mesg[2]);
check("MSG 3",recv_msg[3],i++);
}
benchmark_start_test(&timeInfo);
for (i=0;i<1000;i++)
q_send(qid,mesg);
benchmark_stop_and_report_test(&timeInfo,i,"q_send");
benchmark_start_test(&timeInfo);
for (i=0;i<1000;i++)
q_receive(qid,Q_NOWAIT,0,recv_msg);
benchmark_stop_and_report_test(&timeInfo,i,"q_receive");
check("q_delete",q_delete(qid),0);
}
/*************************************************************************/
static void test_msgqueue_ctxtswitch_body(u_long my_qid,u_long dst_qid,u_long count,u_long tid)
{
unsigned long recv_msg[4];
while (count--)
{
q_receive(my_qid,Q_WAIT,0,recv_msg);
q_send(dst_qid,recv_msg);
}
if (tid)
ev_send(tid,1);
t_delete(0);
}
static void test_msgqueue_ctxtswitch(void)
{
unsigned long tid,ev_rcvd;
unsigned long args[4] = {0,0,0,0};
unsigned long mesg[4] = {0,1,2,3};
unsigned long qid1,qid2;
timestamp_info timeInfo;
my_printf("%s\n",__FUNCTION__);
check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
args[0] = qid1;
args[1] = qid2;
args[2] = 1000;
t_ident(0,0,&args[3]);
check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
args[0] = qid2;
args[1] = qid1;
args[3] = 0; /* Make sure only 1 sends the event. */
check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
/*send initial message */
benchmark_start_test(&timeInfo);
q_send(qid1,mesg);
ev_receive(1,EV_ALL|EV_WAIT,0,&ev_rcvd);
benchmark_stop_and_report_test(&timeInfo,1000,"q_send/q_receive between 2 tasks");
q_delete(qid1);
q_delete(qid2);
}
/*************************************************************************/
static void test_event_ctxtswitch_body(u_long dst_tid,u_long count,u_long tid,u_long d)
{
unsigned long recv_ev;
while (count--)
{
ev_receive(1,EV_WAIT,0,&recv_ev);
ev_send(dst_tid,1);
}
if (tid)
ev_send(tid,1);
t_delete(0);
}
static void test_event_ctxtswitch(void)
{
unsigned long tid1,tid2,ev_rcvd;
unsigned long args[4] = {0,0,0,0};
timestamp_info timeInfo;
my_printf("%s\n",__FUNCTION__);
check("t_create",t_create("TEST",50,16000,16000,0,&tid1),0);
check("t_create",t_create("TEST",50,16000,16000,0,&tid2),0);
args[0] = tid2;
args[1] = 1000;
t_ident(0,0,&args[2]);
check("t_start",t_start(tid1,0,test_event_ctxtswitch_body,args),0);
args[0] = tid1;
args[2] = 0; /* Make sure only 1 sends the event. */
check("t_start",t_start(tid2,0,test_event_ctxtswitch_body,args),0);
/*send initial event */
benchmark_start_test(&timeInfo);
ev_send(tid1,1);
if (ev_receive(1,EV_ALL|EV_WAIT,1000,&ev_rcvd) != 0)
error++;
benchmark_stop_and_report_test(&timeInfo,1000,"q_send/q_receive between 2 tasks");
}
/*************************************************************************/
static void test_semaphores(void)
{
unsigned long smid,smid2;
unsigned long smids[50];
timestamp_info timeInfo;
int i;
my_printf("%s\n",__FUNCTION__);
check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smid),0);
check("sm_ident",sm_ident("TTTT",0,&smid2),0);
check("compare smids",smid,smid2);
check("sm_delete",sm_delete(smid),0);
for (i=0;i<100;i++)
{
check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smid),0);
check("sm_delete",sm_delete(smid),0);
}
for (i=0;i<50;i++)
check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smids[i]),0);
for (i=0;i<50;i++)
check("sm_delete",sm_delete(smids[i]),0);
check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smid),0);
benchmark_start_test(&timeInfo);
for (i=0;i<1000;i++)
{
sm_v(smid);
sm_p(smid,SM_WAIT,0);
}
benchmark_stop_and_report_test(&timeInfo,i,"sm_v/sm_p");
check("sm_delete",sm_delete(smid),0);
}
/*************************************************************************/
static void test_regions(void)
{
void *ptr;
unsigned long rnid,rsize;
my_printf("%s\n",__FUNCTION__);
check("rn_create x",rn_create("TEST",0,128000, 128, 0, &rnid, &rsize),0);
check("rn_getseg x",rn_getseg(rnid,100,RN_NOWAIT,0,&ptr),0);
check("rn_retseg x",rn_retseg(rnid,ptr),0);
check("rn_delete x",rn_delete(rnid),0);
}
static void test_region0_malloc_free(void)
{
void *ptr;
unsigned long i;
my_printf("%s\n",__FUNCTION__);
for (i=0;i<1000;i++)
{
check("rn_getseg 0",rn_getseg(0,100,RN_NOWAIT,0,&ptr),0);
check("rn_retseg 0",rn_retseg(0,ptr),0);
}
}
static void test_timers(void)
{
unsigned long tmr_id,ev_rcvd,ret;
timestamp_info timeInfo;
int i;
ev_receive(1,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
// Test tm_evevery
check("tm_evevery",tm_evevery(1,1,&tmr_id),0);
benchmark_start_test(&timeInfo);
for (i=0;i<11;i++)
{
check("ev_receive",ev_receive(1,EV_ANY|EV_WAIT,100,&ev_rcvd),0);
check("eventmask",ev_rcvd,1);
if (i==10)
check("tm_cancel",tm_cancel(tmr_id),0);
else
benchmark_stop_and_report_test(&timeInfo,i,"tm_evevery 1 (TO %d)",i);
}
ev_rcvd = 0;
ret = ev_receive(1,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
// Test tm_evafter
ev_rcvd = 0;
check("tm_after",tm_evafter(10,2,&tmr_id),0);
check("ev_receive 2",ev_receive(3,EV_ANY|EV_WAIT,20,&ev_rcvd),0);
check("eventmask 2",ev_rcvd,2);
tm_cancel(tmr_id);
tm_wkafter(20);
// Check whether new event is received.
ev_rcvd = 0;
ev_receive(2,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
if (ev_rcvd != 0)
{
my_printf("ev_receive 888 %ld\n",ev_rcvd);
ev_error++;
}
// Test tm_cancel
ev_rcvd = 0;
check("tm_evevery",tm_evevery(3,4,&tmr_id),0);
ret = ev_receive(7,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
my_printf("ev_receive 0 returned %ld (events=%ld)\n",ret,ev_rcvd);
check("tm_cancel",tm_cancel(tmr_id),0);
ev_rcvd = 0;
ret = ev_receive(4,EV_ANY|EV_WAIT,10,&ev_rcvd);
if (ret == 0)
{
ev_error++;
my_printf("ev_receive returned %ld (events=%ld)\n",ret,ev_rcvd);
}
check("ev_receive",ret,ERR_TIMEOUT);
check("tm_evafter",tm_evafter(100,8,&tmr_id),0);
// TODO: The event is receive already after starting the timer.
// If the line below is commented-out the code is not working.
ev_rcvd = 0;
ret = ev_receive(8,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
my_printf("ev_receive 1 returned %ld (events=%ld)\n",ret,ev_rcvd);
check("tm_cancel",tm_cancel(tmr_id),0);
ev_rcvd = 0;
ret = ev_receive(8,EV_ANY|EV_WAIT,200,&ev_rcvd);
my_printf("ev_receive 2 returned %ld (events=%ld)\n",ret,ev_rcvd);
check("ev_receive",ret,ERR_TIMEOUT);
// clear pending events
ev_rcvd = 0;
ev_receive(0xffffffff,EV_ANY|EV_NOWAIT,0,&ev_rcvd);
}
/*************************************************************************/
static void test_timeservices(void)
{
}
static void test_debuginterface(void)
{
unsigned long qid,guard_tmr;
unsigned long mesg[4] = {0,1,2,3};
void *ptr;
unsigned long rnid,rsize;
q_create("0MSG",0,Q_NOLIMIT|Q_PRIOR,&qid);
q_create("1MSG",0,Q_NOLIMIT|Q_PRIOR,&qid);
check("rn_create",rn_create("ISAM",0,128000, 128, 0, &rnid, &rsize),0);
check("rn_getseg 0",rn_getseg(rnid,100,RN_NOWAIT,0,&ptr),0);
my_printf("allocated buffer: %p\n",ptr);
q_send(qid,mesg);
tm_evevery(1000,0x8000,&guard_tmr);
my_printf("TimerId (1000): %ld\n",guard_tmr);
tm_evevery(5000,0x4000,&guard_tmr);
my_printf("TimerId (5000): %ld\n",guard_tmr);
}
/*************************************************************************/
static void test_main_body(u_long destroy,u_long b,u_long c,u_long d);
int main(int argc, char **argv)
{
unsigned long tid;
unsigned long args[4] = {0,0,0,0};
copperplate_init(argc, argv);
check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_main_body,args),0);
while (1) tm_wkafter(1000);
return 0;
}
static void test_main_body(u_long destroy,u_long b,u_long c,u_long d)
{
int i = 0;
char testCaseName[32];
int count = 1000;
for (i=0;i<count;i++)
{
unsigned long tid;
unsigned long args[4] = {0,200,300,400};
sprintf(testCaseName,"t_create %d",i);
check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
sprintf(testCaseName,"t_start %d",i);
check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
sprintf(testCaseName,"t_delete %d",i);
check(testCaseName,t_delete(tid),0);
if ((i%1000) == 0) my_printf("create + start + delete %d\n",i);
}
for (i=0;i<count;i++)
{
unsigned long tid;
unsigned long args[4] = {100,200,300,400};
sprintf(testCaseName,"t_create %d",i);
check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
sprintf(testCaseName,"t_start %d",i);
check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body2,args),0);
if ((i%1000) == 0) my_printf("create + start + self delete %d\n",i);
}
for (i=0;i<count;i++)
{
unsigned long smid;
sprintf(testCaseName,"sm_create %d",i);
check(testCaseName,sm_create("TTTT",0,SM_PRIOR,&smid),0);
sprintf(testCaseName,"sm_delete %d",i);
check(testCaseName,sm_delete(smid),0);
if ((i%1000) == 0) my_printf("sm_create + sm_delete %d\n",i);
}
for (i=0;i<count;i++)
{
unsigned long qid;
sprintf(testCaseName,"q_create %d",i);
check(testCaseName,q_create("TTTT",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
sprintf(testCaseName,"q_delete %d",i);
check(testCaseName,q_delete(qid),0);
if ((i%1000) == 0) my_printf("q_create + q_delete %d\n",i);
}
// Execute this test only once since the kernel memory is mapped into userspace
// and it only released once the process is killed.
test_regions();
test_debuginterface();
i = 0;
while (1)
{
printf("Iteration : %d\n\r",i++);
test_taskcreation();
test_taskregisters();
test_tasksuspend();
test_queuecreation();
test_queue();
test_msgqueue_ctxtswitch();
test_events();
test_event_ctxtswitch();
test_semaphores();
test_region0_malloc_free();
test_timeservices();
test_timers();
tm_wkafter(100);
my_printf_flush();
}
while (1)
tm_wkafter(1000);
}
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-22 20:15 [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin Ronny Meeus
@ 2011-09-23 13:00 ` Philippe Gerum
2011-09-23 20:21 ` Ronny Meeus
2011-09-23 13:56 ` Gilles Chanteperdrix
2011-09-26 10:49 ` Philippe Gerum
2 siblings, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-09-23 13:00 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
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?
>
> This is the version I'm using (downloaded today):
>
> meeusr@domain.hid$ git log | head
> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
> Author: Philippe Gerum <rpm@xenomai.org>
> 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
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-22 20:15 [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin Ronny Meeus
2011-09-23 13:00 ` Philippe Gerum
@ 2011-09-23 13:56 ` Gilles Chanteperdrix
2011-09-23 17:05 ` Ronny Meeus
2011-09-26 10:49 ` Philippe Gerum
2 siblings, 1 reply; 19+ messages in thread
From: Gilles Chanteperdrix @ 2011-09-23 13:56 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On 09/22/2011 10:15 PM, Ronny Meeus wrote:
> Hello
>
> I have created some time ago a test application for the PSOS interface
> of Xenomai.
If you agree, I would like to integrate this test in xenomai-head
regression testsuite.
--
Gilles.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 13:56 ` Gilles Chanteperdrix
@ 2011-09-23 17:05 ` Ronny Meeus
2011-09-23 17:20 ` Gilles Chanteperdrix
0 siblings, 1 reply; 19+ messages in thread
From: Ronny Meeus @ 2011-09-23 17:05 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-help
On Fri, Sep 23, 2011 at 3:56 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 09/22/2011 10:15 PM, Ronny Meeus wrote:
>> Hello
>>
>> I have created some time ago a test application for the PSOS interface
>> of Xenomai.
>
> If you agree, I would like to integrate this test in xenomai-head
> regression testsuite.
>
> --
> Gilles.
>
No problem, the test can be integrated.
Another option is to wait until the code is more clean and the
performance measurement is finished.
I'm planning to do this in the near future.
Regards,
Ronny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 17:05 ` Ronny Meeus
@ 2011-09-23 17:20 ` Gilles Chanteperdrix
2011-09-23 19:58 ` Ronny Meeus
0 siblings, 1 reply; 19+ messages in thread
From: Gilles Chanteperdrix @ 2011-09-23 17:20 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On 09/23/2011 07:05 PM, Ronny Meeus wrote:
> On Fri, Sep 23, 2011 at 3:56 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 09/22/2011 10:15 PM, Ronny Meeus wrote:
>>> Hello
>>>
>>> I have created some time ago a test application for the PSOS interface
>>> of Xenomai.
>>
>> If you agree, I would like to integrate this test in xenomai-head
>> regression testsuite.
>>
>> --
>> Gilles.
>>
>
> No problem, the test can be integrated.
> Another option is to wait until the code is more clean and the
> performance measurement is finished.
> I'm planning to do this in the near future.
I am rather interested in a test (or several tests) whose exit status
indicates whether the tests it contains worked, and which does not take
a long time to execute. The simpler, the better, as this way the test
has fewer chances to contain bugs.
--
Gilles.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 17:20 ` Gilles Chanteperdrix
@ 2011-09-23 19:58 ` Ronny Meeus
0 siblings, 0 replies; 19+ messages in thread
From: Ronny Meeus @ 2011-09-23 19:58 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai-help
On Fri, Sep 23, 2011 at 7:20 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 09/23/2011 07:05 PM, Ronny Meeus wrote:
>> On Fri, Sep 23, 2011 at 3:56 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>>> On 09/22/2011 10:15 PM, Ronny Meeus wrote:
>>>> Hello
>>>>
>>>> I have created some time ago a test application for the PSOS interface
>>>> of Xenomai.
>>>
>>> If you agree, I would like to integrate this test in xenomai-head
>>> regression testsuite.
>>>
>>> --
>>> Gilles.
>>>
>>
>> No problem, the test can be integrated.
>> Another option is to wait until the code is more clean and the
>> performance measurement is finished.
>> I'm planning to do this in the near future.
>
> I am rather interested in a test (or several tests) whose exit status
> indicates whether the tests it contains worked, and which does not take
> a long time to execute. The simpler, the better, as this way the test
> has fewer chances to contain bugs.
>
>
> --
> Gilles.
>
Gilles,
short tests have advantages but long running tests as well.
By running the test program for a long time you can sometimes identify
for example memory leaks, fragmentation or race conditions.
For example all standard psos test (in the testsuite directory) run
without issue on my PC while the test I have created reveals an issue.
So I think both types of tests can be useful.
Ronny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 13:00 ` Philippe Gerum
@ 2011-09-23 20:21 ` Ronny Meeus
2011-09-23 20:23 ` Philippe Gerum
0 siblings, 1 reply; 19+ messages in thread
From: Ronny Meeus @ 2011-09-23 20:21 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-help
On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum <rpm@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@domain.hid$ ./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.
>>
>> This is the version I'm using (downloaded today):
>>
>> meeusr@domain.hid$ git log | head
>> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
>> Author: Philippe Gerum <rpm@xenomai.org>
>> 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
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
> --
> Philippe.
>
>
>
Ronny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 20:21 ` Ronny Meeus
@ 2011-09-23 20:23 ` Philippe Gerum
2011-09-26 10:46 ` Philippe Gerum
0 siblings, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-09-23 20:23 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
> On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum <rpm@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@domain.hid$ ./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@domain.hid$ git log | head
> >> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
> >> Author: Philippe Gerum <rpm@xenomai.org>
> >> 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
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >
> > --
> > Philippe.
> >
> >
> >
>
> Ronny
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-23 20:23 ` Philippe Gerum
@ 2011-09-26 10:46 ` Philippe Gerum
2011-09-26 20:01 ` Ronny Meeus
0 siblings, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-09-26 10:46 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
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 <rpm@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@domain.hid$ ./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.
I reduced the number of test loops as well, since 100 or 1000 loops do
not make any difference. Actually, two consecutive iterations of
t_create/t_delete were enough to trigger the issue.
--- rtprint.c.orig 2011-09-26 12:38:47.711339003 +0200
+++ rtprint.c 2011-09-26 12:37:49.871339005 +0200
@@ -115,7 +115,7 @@
my_printf("%s\n",__FUNCTION__);
- check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
check("t_setreg",t_setreg(tid,0UL,100UL),0);
check("t_getreg",t_getreg(tid,0UL,®_value),0);
check("reg_value",reg_value,100);
@@ -150,7 +150,7 @@
suspendmyself = 0;
- check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_tasksuspend_body,args),0);
counter = 0;
@@ -201,7 +201,7 @@
static void create_and_start_task(unsigned long *tid)
{
unsigned long local_args[4] = {0,200,300,400};
- check("t_create low prio",t_create ("TEST",2,4000,0,T_LOCAL,tid),0);
+ check("t_create low prio",t_create (NULL,2,4000,0,T_LOCAL,tid),0);
check("t_start low prio",t_start(*tid,T_PREEMPT|T_TSLICE,test_taskcreation_body,local_args),0);
}
@@ -219,7 +219,7 @@
for (i=1;i<2;i++)
{
- check("t_create",t_create("TEST",(unsigned long)i,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,(unsigned long)i,16000,16000,0,&tid),0);
check("t_start",t_start(tid,T_PREEMPT| T_TSLICE | T_NOASR,test_taskcreation_body2,args),0);
}
@@ -260,7 +260,7 @@
args[0] = 0;
for (i=0;i<500;i++)
{
- check("t_create loop3",t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
+ check("t_create loop3",t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
check("t_start loop3",t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
check("t_delete loop3",t_delete(tid),0);
my_printf("t_create + t_start + t_delete %d\r",i);
@@ -334,7 +334,7 @@
test_basicevents();
t_ident(0,0,&args[0]);
- check("t_create",t_create("TEST",2,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,2,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_events_body,args),0);
ev_receive(1,EV_ALL|EV_WAIT,0,&ev_rcvd);
@@ -361,7 +361,7 @@
}
for (i=0;i<50;i++)
- check("q_create",q_create("TTTU",0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
+ check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
for (i=0;i<50;i++)
check("q_delete",q_delete(qids[i]),0);
}
@@ -439,20 +439,20 @@
my_printf("%s\n",__FUNCTION__);
- check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
- check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
+ check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
+ check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
args[0] = qid1;
args[1] = qid2;
args[2] = 1000;
t_ident(0,0,&args[3]);
- check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
args[0] = qid2;
args[1] = qid1;
args[3] = 0; /* Make sure only 1 sends the event. */
- check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
+ check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
/*send initial message */
@@ -490,8 +490,8 @@
my_printf("%s\n",__FUNCTION__);
- check("t_create",t_create("TEST",50,16000,16000,0,&tid1),0);
- check("t_create",t_create("TEST",50,16000,16000,0,&tid2),0);
+ check("t_create",t_create(NULL,50,16000,16000,0,&tid1),0);
+ check("t_create",t_create(NULL,50,16000,16000,0,&tid2),0);
args[0] = tid2;
args[1] = 1000;
@@ -533,7 +533,7 @@
}
for (i=0;i<50;i++)
- check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smids[i]),0);
+ check("sm_create",sm_create(NULL,0,SM_PRIOR,&smids[i]),0);
for (i=0;i<50;i++)
check("sm_delete",sm_delete(smids[i]),0);
@@ -690,7 +690,7 @@
copperplate_init(argc, argv);
- check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
+ check("t_create",t_create("ROOT",50,16000,16000,0,&tid),0);
check("t_start",t_start(tid,0,test_main_body,args),0);
while (1) tm_wkafter(1000);
@@ -703,7 +703,7 @@
{
int i = 0;
char testCaseName[32];
- int count = 1000;
+ int count = 100;
for (i=0;i<count;i++)
{
@@ -711,12 +711,12 @@
unsigned long args[4] = {0,200,300,400};
sprintf(testCaseName,"t_create %d",i);
- check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
+ check(testCaseName,t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
sprintf(testCaseName,"t_start %d",i);
check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
sprintf(testCaseName,"t_delete %d",i);
check(testCaseName,t_delete(tid),0);
- if ((i%1000) == 0) my_printf("create + start + delete %d\n",i);
+ if ((i%100) == 0) my_printf("create + start + delete %d\n",i);
}
for (i=0;i<count;i++)
@@ -725,10 +725,10 @@
unsigned long args[4] = {100,200,300,400};
sprintf(testCaseName,"t_create %d",i);
- check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
+ check(testCaseName,t_create (NULL,(i%96)+1,100000,0,0,&tid),0);
sprintf(testCaseName,"t_start %d",i);
check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body2,args),0);
- if ((i%1000) == 0) my_printf("create + start + self delete %d\n",i);
+ if ((i%100) == 0) my_printf("create + start + self delete %d\n",i);
}
for (i=0;i<count;i++)
@@ -739,7 +739,7 @@
check(testCaseName,sm_create("TTTT",0,SM_PRIOR,&smid),0);
sprintf(testCaseName,"sm_delete %d",i);
check(testCaseName,sm_delete(smid),0);
- if ((i%1000) == 0) my_printf("sm_create + sm_delete %d\n",i);
+ if ((i%100) == 0) my_printf("sm_create + sm_delete %d\n",i);
}
for (i=0;i<count;i++)
@@ -750,7 +750,7 @@
check(testCaseName,q_create("TTTT",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
sprintf(testCaseName,"q_delete %d",i);
check(testCaseName,q_delete(qid),0);
- if ((i%1000) == 0) my_printf("q_create + q_delete %d\n",i);
+ if ((i%100) == 0) my_printf("q_create + q_delete %d\n",i);
}
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-22 20:15 [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin Ronny Meeus
2011-09-23 13:00 ` Philippe Gerum
2011-09-23 13:56 ` Gilles Chanteperdrix
@ 2011-09-26 10:49 ` Philippe Gerum
2011-09-26 20:02 ` Ronny Meeus
2 siblings, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-09-26 10:49 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
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.
> 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@domain.hid$ git log | head
> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
> Author: Philippe Gerum <rpm@xenomai.org>
> 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
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 10:46 ` Philippe Gerum
@ 2011-09-26 20:01 ` Ronny Meeus
2011-09-26 21:11 ` Philippe Gerum
2011-10-04 15:41 ` Philippe Gerum
0 siblings, 2 replies; 19+ messages in thread
From: Ronny Meeus @ 2011-09-26 20:01 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-help
On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerum <rpm@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 <rpm@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@domain.hid$ ./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@domain.hid", 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.
Next to this I also adapted the task priority automatically using
following algorithm:
static int check_task_priority(u_long *psos_prio)
{
if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
return ERR_PRIOR;
/* Do not change priorities <=10 and >= 240.
* Priorities in between are divided by 4 */
if (*psos_prio > 240)
*psos_prio = 70 + *psos_prio - 240;
else if (*psos_prio > 10)
*psos_prio = 11 + ((*psos_prio-10)/4);
if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
panic("current implementation restricts pSOS "
"priority levels to range [1..%d]",
threadobj_max_prio - 2);
return SUCCESS;
}
It also works well for our application.
Please share your thoughts.
>
> I reduced the number of test loops as well, since 100 or 1000 loops do
> not make any difference. Actually, two consecutive iterations of
> t_create/t_delete were enough to trigger the issue.
>
> --- rtprint.c.orig 2011-09-26 12:38:47.711339003 +0200
> +++ rtprint.c 2011-09-26 12:37:49.871339005 +0200
> @@ -115,7 +115,7 @@
>
> my_printf("%s\n",__FUNCTION__);
>
> - check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
> check("t_setreg",t_setreg(tid,0UL,100UL),0);
> check("t_getreg",t_getreg(tid,0UL,®_value),0);
> check("reg_value",reg_value,100);
> @@ -150,7 +150,7 @@
>
> suspendmyself = 0;
>
> - check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,0,test_tasksuspend_body,args),0);
>
> counter = 0;
> @@ -201,7 +201,7 @@
> static void create_and_start_task(unsigned long *tid)
> {
> unsigned long local_args[4] = {0,200,300,400};
> - check("t_create low prio",t_create ("TEST",2,4000,0,T_LOCAL,tid),0);
> + check("t_create low prio",t_create (NULL,2,4000,0,T_LOCAL,tid),0);
> check("t_start low prio",t_start(*tid,T_PREEMPT|T_TSLICE,test_taskcreation_body,local_args),0);
> }
>
> @@ -219,7 +219,7 @@
>
> for (i=1;i<2;i++)
> {
> - check("t_create",t_create("TEST",(unsigned long)i,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,(unsigned long)i,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,T_PREEMPT| T_TSLICE | T_NOASR,test_taskcreation_body2,args),0);
> }
>
> @@ -260,7 +260,7 @@
> args[0] = 0;
> for (i=0;i<500;i++)
> {
> - check("t_create loop3",t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> + check("t_create loop3",t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
> check("t_start loop3",t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
> check("t_delete loop3",t_delete(tid),0);
> my_printf("t_create + t_start + t_delete %d\r",i);
> @@ -334,7 +334,7 @@
> test_basicevents();
>
> t_ident(0,0,&args[0]);
> - check("t_create",t_create("TEST",2,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,2,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,0,test_events_body,args),0);
>
> ev_receive(1,EV_ALL|EV_WAIT,0,&ev_rcvd);
> @@ -361,7 +361,7 @@
> }
>
> for (i=0;i<50;i++)
> - check("q_create",q_create("TTTU",0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
> + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
> for (i=0;i<50;i++)
> check("q_delete",q_delete(qids[i]),0);
> }
> @@ -439,20 +439,20 @@
>
> my_printf("%s\n",__FUNCTION__);
>
> - check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
> - check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
> + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
> + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
>
> args[0] = qid1;
> args[1] = qid2;
> args[2] = 1000;
> t_ident(0,0,&args[3]);
> - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
>
> args[0] = qid2;
> args[1] = qid1;
> args[3] = 0; /* Make sure only 1 sends the event. */
> - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> + check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
>
> /*send initial message */
> @@ -490,8 +490,8 @@
>
> my_printf("%s\n",__FUNCTION__);
>
> - check("t_create",t_create("TEST",50,16000,16000,0,&tid1),0);
> - check("t_create",t_create("TEST",50,16000,16000,0,&tid2),0);
> + check("t_create",t_create(NULL,50,16000,16000,0,&tid1),0);
> + check("t_create",t_create(NULL,50,16000,16000,0,&tid2),0);
>
> args[0] = tid2;
> args[1] = 1000;
> @@ -533,7 +533,7 @@
> }
>
> for (i=0;i<50;i++)
> - check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smids[i]),0);
> + check("sm_create",sm_create(NULL,0,SM_PRIOR,&smids[i]),0);
> for (i=0;i<50;i++)
> check("sm_delete",sm_delete(smids[i]),0);
>
> @@ -690,7 +690,7 @@
>
> copperplate_init(argc, argv);
>
> - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> + check("t_create",t_create("ROOT",50,16000,16000,0,&tid),0);
> check("t_start",t_start(tid,0,test_main_body,args),0);
>
> while (1) tm_wkafter(1000);
> @@ -703,7 +703,7 @@
> {
> int i = 0;
> char testCaseName[32];
> - int count = 1000;
> + int count = 100;
>
> for (i=0;i<count;i++)
> {
> @@ -711,12 +711,12 @@
> unsigned long args[4] = {0,200,300,400};
>
> sprintf(testCaseName,"t_create %d",i);
> - check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> + check(testCaseName,t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
> sprintf(testCaseName,"t_start %d",i);
> check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
> sprintf(testCaseName,"t_delete %d",i);
> check(testCaseName,t_delete(tid),0);
> - if ((i%1000) == 0) my_printf("create + start + delete %d\n",i);
> + if ((i%100) == 0) my_printf("create + start + delete %d\n",i);
> }
>
> for (i=0;i<count;i++)
> @@ -725,10 +725,10 @@
> unsigned long args[4] = {100,200,300,400};
>
> sprintf(testCaseName,"t_create %d",i);
> - check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> + check(testCaseName,t_create (NULL,(i%96)+1,100000,0,0,&tid),0);
> sprintf(testCaseName,"t_start %d",i);
> check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body2,args),0);
> - if ((i%1000) == 0) my_printf("create + start + self delete %d\n",i);
> + if ((i%100) == 0) my_printf("create + start + self delete %d\n",i);
> }
>
> for (i=0;i<count;i++)
> @@ -739,7 +739,7 @@
> check(testCaseName,sm_create("TTTT",0,SM_PRIOR,&smid),0);
> sprintf(testCaseName,"sm_delete %d",i);
> check(testCaseName,sm_delete(smid),0);
> - if ((i%1000) == 0) my_printf("sm_create + sm_delete %d\n",i);
> + if ((i%100) == 0) my_printf("sm_create + sm_delete %d\n",i);
> }
>
> for (i=0;i<count;i++)
> @@ -750,7 +750,7 @@
> check(testCaseName,q_create("TTTT",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
> sprintf(testCaseName,"q_delete %d",i);
> check(testCaseName,q_delete(qid),0);
> - if ((i%1000) == 0) my_printf("q_create + q_delete %d\n",i);
> + if ((i%100) == 0) my_printf("q_create + q_delete %d\n",i);
> }
>
> --
> Philippe.
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 10:49 ` Philippe Gerum
@ 2011-09-26 20:02 ` Ronny Meeus
2011-09-26 20:57 ` Philippe Gerum
0 siblings, 1 reply; 19+ messages in thread
From: Ronny Meeus @ 2011-09-26 20:02 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-help
On Mon, Sep 26, 2011 at 12:49 PM, Philippe Gerum <rpm@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.
>
> 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@domain.hid$ git log | head
>> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
>> Author: Philippe Gerum <rpm@xenomai.org>
>> 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
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>
> --
> Philippe.
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 20:02 ` Ronny Meeus
@ 2011-09-26 20:57 ` Philippe Gerum
0 siblings, 0 replies; 19+ messages in thread
From: Philippe Gerum @ 2011-09-26 20:57 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On Mon, 2011-09-26 at 22:02 +0200, Ronny Meeus wrote:
> On Mon, Sep 26, 2011 at 12:49 PM, Philippe Gerum <rpm@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.
> >
> > 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.
The task name issue is not related to the current synchronization bug in
all 2.x series for creating pSOS tasks. Regardless of their names, pSOS
tasks in 2.x are potentially at risk if t_delete() is issued for them
while emerging in the task trampoline code.
>
> >
> >> 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@domain.hid$ git log | head
> >> commit 04b776ed9ff18e197ae43ee552b8e77f42c5e5cb
> >> Author: Philippe Gerum <rpm@xenomai.org>
> >> 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
> >> Xenomai-help@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-help
> >
> > --
> > Philippe.
> >
> >
> >
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 20:01 ` Ronny Meeus
@ 2011-09-26 21:11 ` Philippe Gerum
2011-11-01 11:52 ` Philippe Gerum
2011-10-04 15:41 ` Philippe Gerum
1 sibling, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-09-26 21:11 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
> On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerum <rpm@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 <rpm@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@domain.hid$ ./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@domain.hid", 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.
>
Which demonstrates that t_ident() is broken by design since pSOS does
not enforce name uniqueness, anyway.
>
> Next to this I also adapted the task priority automatically using
> following algorithm:
> static int check_task_priority(u_long *psos_prio)
> {
> if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
> return ERR_PRIOR;
> /* Do not change priorities <=10 and >= 240.
> * Priorities in between are divided by 4 */
> if (*psos_prio > 240)
> *psos_prio = 70 + *psos_prio - 240;
> else if (*psos_prio > 10)
> *psos_prio = 11 + ((*psos_prio-10)/4);
>
> if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
> panic("current implementation restricts pSOS "
> "priority levels to range [1..%d]",
> threadobj_max_prio - 2);
>
> return SUCCESS;
> }
>
> It also works well for our application.
> Please share your thoughts.
I don't think we could generalize any of the name and priority mappings
your application does, which means that we need some sort of optional
hook to be called from the emulation core into the user-level code, to
give the application an opportunity to translate such info the way it
wants.
>
> >
> > I reduced the number of test loops as well, since 100 or 1000 loops do
> > not make any difference. Actually, two consecutive iterations of
> > t_create/t_delete were enough to trigger the issue.
> >
> > --- rtprint.c.orig 2011-09-26 12:38:47.711339003 +0200
> > +++ rtprint.c 2011-09-26 12:37:49.871339005 +0200
> > @@ -115,7 +115,7 @@
> >
> > my_printf("%s\n",__FUNCTION__);
> >
> > - check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
> > check("t_setreg",t_setreg(tid,0UL,100UL),0);
> > check("t_getreg",t_getreg(tid,0UL,®_value),0);
> > check("reg_value",reg_value,100);
> > @@ -150,7 +150,7 @@
> >
> > suspendmyself = 0;
> >
> > - check("t_create",t_create("TEST",250,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,96,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,0,test_tasksuspend_body,args),0);
> >
> > counter = 0;
> > @@ -201,7 +201,7 @@
> > static void create_and_start_task(unsigned long *tid)
> > {
> > unsigned long local_args[4] = {0,200,300,400};
> > - check("t_create low prio",t_create ("TEST",2,4000,0,T_LOCAL,tid),0);
> > + check("t_create low prio",t_create (NULL,2,4000,0,T_LOCAL,tid),0);
> > check("t_start low prio",t_start(*tid,T_PREEMPT|T_TSLICE,test_taskcreation_body,local_args),0);
> > }
> >
> > @@ -219,7 +219,7 @@
> >
> > for (i=1;i<2;i++)
> > {
> > - check("t_create",t_create("TEST",(unsigned long)i,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,(unsigned long)i,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,T_PREEMPT| T_TSLICE | T_NOASR,test_taskcreation_body2,args),0);
> > }
> >
> > @@ -260,7 +260,7 @@
> > args[0] = 0;
> > for (i=0;i<500;i++)
> > {
> > - check("t_create loop3",t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> > + check("t_create loop3",t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
> > check("t_start loop3",t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
> > check("t_delete loop3",t_delete(tid),0);
> > my_printf("t_create + t_start + t_delete %d\r",i);
> > @@ -334,7 +334,7 @@
> > test_basicevents();
> >
> > t_ident(0,0,&args[0]);
> > - check("t_create",t_create("TEST",2,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,2,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,0,test_events_body,args),0);
> >
> > ev_receive(1,EV_ALL|EV_WAIT,0,&ev_rcvd);
> > @@ -361,7 +361,7 @@
> > }
> >
> > for (i=0;i<50;i++)
> > - check("q_create",q_create("TTTU",0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
> > + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qids[i]),0);
> > for (i=0;i<50;i++)
> > check("q_delete",q_delete(qids[i]),0);
> > }
> > @@ -439,20 +439,20 @@
> >
> > my_printf("%s\n",__FUNCTION__);
> >
> > - check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
> > - check("q_create",q_create("TEST",0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
> > + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid1),0);
> > + check("q_create",q_create(NULL,0,Q_NOLIMIT|Q_PRIOR,&qid2),0);
> >
> > args[0] = qid1;
> > args[1] = qid2;
> > args[2] = 1000;
> > t_ident(0,0,&args[3]);
> > - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
> >
> > args[0] = qid2;
> > args[1] = qid1;
> > args[3] = 0; /* Make sure only 1 sends the event. */
> > - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> > + check("t_create",t_create(NULL,50,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,0,test_msgqueue_ctxtswitch_body,args),0);
> >
> > /*send initial message */
> > @@ -490,8 +490,8 @@
> >
> > my_printf("%s\n",__FUNCTION__);
> >
> > - check("t_create",t_create("TEST",50,16000,16000,0,&tid1),0);
> > - check("t_create",t_create("TEST",50,16000,16000,0,&tid2),0);
> > + check("t_create",t_create(NULL,50,16000,16000,0,&tid1),0);
> > + check("t_create",t_create(NULL,50,16000,16000,0,&tid2),0);
> >
> > args[0] = tid2;
> > args[1] = 1000;
> > @@ -533,7 +533,7 @@
> > }
> >
> > for (i=0;i<50;i++)
> > - check("sm_create",sm_create("TTTT",0,SM_PRIOR,&smids[i]),0);
> > + check("sm_create",sm_create(NULL,0,SM_PRIOR,&smids[i]),0);
> > for (i=0;i<50;i++)
> > check("sm_delete",sm_delete(smids[i]),0);
> >
> > @@ -690,7 +690,7 @@
> >
> > copperplate_init(argc, argv);
> >
> > - check("t_create",t_create("TEST",50,16000,16000,0,&tid),0);
> > + check("t_create",t_create("ROOT",50,16000,16000,0,&tid),0);
> > check("t_start",t_start(tid,0,test_main_body,args),0);
> >
> > while (1) tm_wkafter(1000);
> > @@ -703,7 +703,7 @@
> > {
> > int i = 0;
> > char testCaseName[32];
> > - int count = 1000;
> > + int count = 100;
> >
> > for (i=0;i<count;i++)
> > {
> > @@ -711,12 +711,12 @@
> > unsigned long args[4] = {0,200,300,400};
> >
> > sprintf(testCaseName,"t_create %d",i);
> > - check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> > + check(testCaseName,t_create ("TEST",(i%96)+1,100000,0,0,&tid),0);
> > sprintf(testCaseName,"t_start %d",i);
> > check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body,args),0);
> > sprintf(testCaseName,"t_delete %d",i);
> > check(testCaseName,t_delete(tid),0);
> > - if ((i%1000) == 0) my_printf("create + start + delete %d\n",i);
> > + if ((i%100) == 0) my_printf("create + start + delete %d\n",i);
> > }
> >
> > for (i=0;i<count;i++)
> > @@ -725,10 +725,10 @@
> > unsigned long args[4] = {100,200,300,400};
> >
> > sprintf(testCaseName,"t_create %d",i);
> > - check(testCaseName,t_create ("TEST",(i%250)+1,100000,0,0,&tid),0);
> > + check(testCaseName,t_create (NULL,(i%96)+1,100000,0,0,&tid),0);
> > sprintf(testCaseName,"t_start %d",i);
> > check(testCaseName,t_start(tid,T_PREEMPT,test_taskcreation_body2,args),0);
> > - if ((i%1000) == 0) my_printf("create + start + self delete %d\n",i);
> > + if ((i%100) == 0) my_printf("create + start + self delete %d\n",i);
> > }
> >
> > for (i=0;i<count;i++)
> > @@ -739,7 +739,7 @@
> > check(testCaseName,sm_create("TTTT",0,SM_PRIOR,&smid),0);
> > sprintf(testCaseName,"sm_delete %d",i);
> > check(testCaseName,sm_delete(smid),0);
> > - if ((i%1000) == 0) my_printf("sm_create + sm_delete %d\n",i);
> > + if ((i%100) == 0) my_printf("sm_create + sm_delete %d\n",i);
> > }
> >
> > for (i=0;i<count;i++)
> > @@ -750,7 +750,7 @@
> > check(testCaseName,q_create("TTTT",0,Q_NOLIMIT|Q_PRIOR,&qid),0);
> > sprintf(testCaseName,"q_delete %d",i);
> > check(testCaseName,q_delete(qid),0);
> > - if ((i%1000) == 0) my_printf("q_create + q_delete %d\n",i);
> > + if ((i%100) == 0) my_printf("q_create + q_delete %d\n",i);
> > }
> >
> > --
> > Philippe.
> >
> >
> >
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 20:01 ` Ronny Meeus
2011-09-26 21:11 ` Philippe Gerum
@ 2011-10-04 15:41 ` Philippe Gerum
2011-10-12 17:16 ` Ronny Meeus
1 sibling, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-10-04 15:41 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
<snip>
> Next to this I also adapted the task priority automatically using
> following algorithm:
> static int check_task_priority(u_long *psos_prio)
> {
> if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
> return ERR_PRIOR;
> /* Do not change priorities <=10 and >= 240.
> * Priorities in between are divided by 4 */
> if (*psos_prio > 240)
> *psos_prio = 70 + *psos_prio - 240;
> else if (*psos_prio > 10)
> *psos_prio = 11 + ((*psos_prio-10)/4);
>
> if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
> panic("current implementation restricts pSOS "
> "priority levels to range [1..%d]",
> threadobj_max_prio - 2);
>
> return SUCCESS;
> }
>
> It also works well for our application.
> Please share your thoughts.
Since we cannot generalize the priority mapping rules, a better way may
be to allow your own code to be called by the pSOS emulator when such
mapping is required. So I have committed a tentative solution, defining
psos_task_normalize_priority() as a weak function, which receives the
pSOS priority, and should return the POSIX one.
A default implementation is provided by the emulator which does a
trivial 1:1 mapping.
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-10-04 15:41 ` Philippe Gerum
@ 2011-10-12 17:16 ` Ronny Meeus
2011-10-12 17:19 ` Philippe Gerum
0 siblings, 1 reply; 19+ messages in thread
From: Ronny Meeus @ 2011-10-12 17:16 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-help
On Tue, Oct 4, 2011 at 5:41 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
>
> <snip>
>
>> Next to this I also adapted the task priority automatically using
>> following algorithm:
>> static int check_task_priority(u_long *psos_prio)
>> {
>> if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
>> return ERR_PRIOR;
>> /* Do not change priorities <=10 and >= 240.
>> * Priorities in between are divided by 4 */
>> if (*psos_prio > 240)
>> *psos_prio = 70 + *psos_prio - 240;
>> else if (*psos_prio > 10)
>> *psos_prio = 11 + ((*psos_prio-10)/4);
>>
>> if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
>> panic("current implementation restricts pSOS "
>> "priority levels to range [1..%d]",
>> threadobj_max_prio - 2);
>>
>> return SUCCESS;
>> }
>>
>> It also works well for our application.
>> Please share your thoughts.
>
> Since we cannot generalize the priority mapping rules, a better way may
> be to allow your own code to be called by the pSOS emulator when such
> mapping is required. So I have committed a tentative solution, defining
> psos_task_normalize_priority() as a weak function, which receives the
> pSOS priority, and should return the POSIX one.
>
> A default implementation is provided by the emulator which does a
> trivial 1:1 mapping.
>
> --
> Philippe.
>
>
>
Philippe
as Thomas indicated in his mail today (see PSOS skin: mismatch in
function signatures cause buffer overflow), we synced with the forge
repo. We used this psos_task_normalize_priority function to remap the
priority for our application and it works well.
Thanks.
Ronny
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-10-12 17:16 ` Ronny Meeus
@ 2011-10-12 17:19 ` Philippe Gerum
0 siblings, 0 replies; 19+ messages in thread
From: Philippe Gerum @ 2011-10-12 17:19 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
On Wed, 2011-10-12 at 19:16 +0200, Ronny Meeus wrote:
> On Tue, Oct 4, 2011 at 5:41 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> > On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
> >
> > <snip>
> >
> >> Next to this I also adapted the task priority automatically using
> >> following algorithm:
> >> static int check_task_priority(u_long *psos_prio)
> >> {
> >> if (*psos_prio < 1 || *psos_prio > 255) /* In theory. */
> >> return ERR_PRIOR;
> >> /* Do not change priorities <=10 and >= 240.
> >> * Priorities in between are divided by 4 */
> >> if (*psos_prio > 240)
> >> *psos_prio = 70 + *psos_prio - 240;
> >> else if (*psos_prio > 10)
> >> *psos_prio = 11 + ((*psos_prio-10)/4);
> >>
> >> if ((int)(*psos_prio) >= threadobj_max_prio - 1) /* In practice. */
> >> panic("current implementation restricts pSOS "
> >> "priority levels to range [1..%d]",
> >> threadobj_max_prio - 2);
> >>
> >> return SUCCESS;
> >> }
> >>
> >> It also works well for our application.
> >> Please share your thoughts.
> >
> > Since we cannot generalize the priority mapping rules, a better way may
> > be to allow your own code to be called by the pSOS emulator when such
> > mapping is required. So I have committed a tentative solution, defining
> > psos_task_normalize_priority() as a weak function, which receives the
> > pSOS priority, and should return the POSIX one.
> >
> > A default implementation is provided by the emulator which does a
> > trivial 1:1 mapping.
> >
> > --
> > Philippe.
> >
> >
> >
>
> Philippe
>
> as Thomas indicated in his mail today (see PSOS skin: mismatch in
> function signatures cause buffer overflow), we synced with the forge
> repo. We used this psos_task_normalize_priority function to remap the
> priority for our application and it works well.
> Thanks.
Ok, so this interface is now official. Thanks.
>
> Ronny
--
Philippe.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-09-26 21:11 ` Philippe Gerum
@ 2011-11-01 11:52 ` Philippe Gerum
2011-11-18 10:57 ` Thomas De Schampheleire
0 siblings, 1 reply; 19+ messages in thread
From: Philippe Gerum @ 2011-11-01 11:52 UTC (permalink / raw)
To: Ronny Meeus; +Cc: xenomai-help
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<rpm@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<rpm@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@domain.hid$ ./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@domain.hid", 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin
2011-11-01 11:52 ` Philippe Gerum
@ 2011-11-18 10:57 ` Thomas De Schampheleire
0 siblings, 0 replies; 19+ messages in thread
From: Thomas De Schampheleire @ 2011-11-18 10:57 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-help
On Tue, Nov 1, 2011 at 12:52 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> 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<rpm@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<rpm@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@domain.hid$ ./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@domain.hid", 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.
I tested this new implementation now. It seems to work fine, thanks.
One side note: in one of the changes in -forge, a new file
'internal.h' was added, and the definition of __this_node was moved
away from include/copperplate/init.h. This breaks compilation of
-forge if you enabled the registry support.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-11-18 10:57 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-22 20:15 [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin Ronny Meeus
2011-09-23 13:00 ` Philippe Gerum
2011-09-23 20:21 ` Ronny Meeus
2011-09-23 20:23 ` Philippe Gerum
2011-09-26 10:46 ` Philippe Gerum
2011-09-26 20:01 ` Ronny Meeus
2011-09-26 21:11 ` Philippe Gerum
2011-11-01 11:52 ` Philippe Gerum
2011-11-18 10:57 ` Thomas De Schampheleire
2011-10-04 15:41 ` Philippe Gerum
2011-10-12 17:16 ` Ronny Meeus
2011-10-12 17:19 ` Philippe Gerum
2011-09-23 13:56 ` Gilles Chanteperdrix
2011-09-23 17:05 ` Ronny Meeus
2011-09-23 17:20 ` Gilles Chanteperdrix
2011-09-23 19:58 ` Ronny Meeus
2011-09-26 10:49 ` Philippe Gerum
2011-09-26 20:02 ` Ronny Meeus
2011-09-26 20:57 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.