Hello it is me again.
This is the configuration I'm using: Target based on QEMU, Xenomai 2.5.4 and the PSOS skin. [ 0.623238] Xenomai: hal/i386 started. [ 0.633758] Xenomai: scheduling class idle registered. [ 0.636172] Xenomai: scheduling class rt registered. [ 0.693178] Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded. [ 0.723234] Xenomai: starting native API services. [ 0.728107] Xenomai: starting pSOS+ services. I sometimes observe issues in passing task arguments to the taskbody of the pSOS task. Observations: 1 During debugging I observe in 50% of the cases that all arguments of some task are 0 (all 4). There is no issue with this task if the debugger is not used. 2 During a task creation (in some scenarios) I see in 100% of the cases that all arguments are 0 while the parameters are fine for other application scenarios where the same code is used to create the task itself. Conclusion: strange behavior is seen (looks like a race condition ...). I did already some research in the code and on the web and came across following thread: http://www.mail-archive.com/[email protected]/msg04470.html This explains the mechanism and also talks about a problem that has been resolved in this area. I think there is still a gap somewhere. This is how our code looks like (I removed the error checking for ease of reading): taskbody: void TaskApp::appTaskEntry(TaskApp *task) { task->appTaskCode(); } start_function: unsigned long targs[4] = {this,0,0,0}; t_create(appTaskName_m,arg1_m,2048,0,0,&appTaskId_m); t_start(appTaskId_m,tMode_m,(void (*)())appTaskEntry,targs); As you can see the task arguments array is created on the stack of the calling task. Like I stated before, for some scenarios, this code is working fine, but for other scenarios, it crashed while dereferencing the task pointer in the "appTaskEntry" function. For testing purposes I replaced the above code by: unsigned long *targs = (unsigned long*)malloc(16); targs[0] = (unsigned long)this; targs[1] = targs[2] = targs[3] = 0; t_create(appTaskName_m,arg1_m,2048,0,0,&appTaskId_m); t_start(appTaskId_m,tMode_m,appTaskEntry,targs); In this code I allocate the task array on the heap and never destroy it (I know I have a memory leak). After this change the code is working well and I never see an issue. I already tried to create a simple example to narrow down the bad scenario but I failed to reproduce it in a small testbuild. Any suggestions are welcome. Many thanks. Best regards, Ronny
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
