Hi Mariusz,
On Thu, Jan 3, 2013 at 2:49 PM, <mariuszjaniak [..] ...> wrote:
>
Hi
>
> I have just installed Orocos 2.6 on a fresh Xenomai 2.6.2 revision hosted
> by
> Ubuntu 12.10 x86_64. A problem appears when I run helloWord example
>
> WARNING: You are not root. This program *may* require that you are root.
> 0.045 [ Info ][main()] ./helloworld manually raises LogLevel to 'Info'
> (5).
> See also file 'orocos.log'.
> 0.045 [ Info ][main()] **** Creating the 'Hello' component ****
> 0.045 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER,
> priority=1, CPU affinity=0, with name='Hello'
> 0.046 [ Info ][Hello] Thread created with scheduler type
> 'ORO_SCHED_OTHER',
> priority 1, cpu affinity 0 and period 0 (PID= 0 ).
> 0.046 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER,
> priority=1, CPU affinity=0, with name='GlobalEngine'
> 0.046 [ Info ][GlobalEngine] Thread created with scheduler type
> 'ORO_SCHED_OTHER', priority 1, cpu affinity 0 and period 0 (PID= 0 ).
> 0.047 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_RT,
> priority=0, CPU affinity=0, with name='Activity'
> 0.047 [ Info ][Activity] Thread created with scheduler type
> 'ORO_SCHED_RT',
> priority 0, cpu affinity 0 and period 0.1 (PID= 0 ).
> CPU time limit exceeded (core dumped)
>
> The same problem appears during exiting from deployer-xenomai (I am able to
> run deployer without problems).
>
> Last few lines from strace ./helloWord are following
>
> write(3, "0.060 [ Info ][GlobalEngine] T"..., 136) = 136
>
> I have just installed Orocos 2.6 on a fresh Xenomai 2.6.2 revision hosted
> by
> Ubuntu 12.10 x86_64. A problem appears when I run helloWord example
>
> WARNING: You are not root. This program *may* require that you are root.
> 0.045 [ Info ][main()] ./helloworld manually raises LogLevel to 'Info'
> (5).
> See also file 'orocos.log'.
> 0.045 [ Info ][main()] **** Creating the 'Hello' component ****
> 0.045 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER,
> priority=1, CPU affinity=0, with name='Hello'
> 0.046 [ Info ][Hello] Thread created with scheduler type
> 'ORO_SCHED_OTHER',
> priority 1, cpu affinity 0 and period 0 (PID= 0 ).
> 0.046 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_OTHER,
> priority=1, CPU affinity=0, with name='GlobalEngine'
> 0.046 [ Info ][GlobalEngine] Thread created with scheduler type
> 'ORO_SCHED_OTHER', priority 1, cpu affinity 0 and period 0 (PID= 0 ).
> 0.047 [ Info ][Thread] Creating Thread for scheduler=ORO_SCHED_RT,
> priority=0, CPU affinity=0, with name='Activity'
> 0.047 [ Info ][Activity] Thread created with scheduler type
> 'ORO_SCHED_RT',
> priority 0, cpu affinity 0 and period 0.1 (PID= 0 ).
> CPU time limit exceeded (core dumped)
>
> The same problem appears during exiting from deployer-xenomai (I am able to
> run deployer without problems).
>
> Last few lines from strace ./helloWord are following
>
> write(3, "0.060 [ Info ][GlobalEngine] T"..., 136) = 136
Orocos 2.6, Xenomai 2.6.2 and SIGXCPU
Orocos 2.6, Xenomai 2.6.2 and SIGXCPU
Orocos 2.6, Xenomai 2.6.2 and SIGXCPU
Hi Mariusz,
On Tue, Jan 8, 2013 at 11:30 AM, Mariusz Janiak <mariuszjaniak [..] ...> wrote:
>
> Thanks for the digging. Your example should end at least like this:
>
> /* Thread::~Thread() in Thread.cpp:326 -- automatic in destructor when
> TaskContext::setActivity(...) is called by HelloWord object (default
> activity created in object constructor is replaced by new activity)*/
>
> /* Do something */
> sleep(1);
> rt_task_join(&testtask); // done in Thread::terminate()
> rt_task_delete(&testTask);
>
> rt_mutex_acquire(&mutex, TM_NONBLOCK); // done in MutexRecursive
> destructor.
> rt_mutex_release(&mutex); // we get the SIG here.
>
> So first join & delete and then lock/unlock and then release the mutex.
>
> I didn't go into the details of your example, so there might be other
> discrepancies too.
>
> It is true what Gilles is saying, the Main thread is running in
> SCHED_OTHER, so every
> mutex release by the main thread may cause this signal. What I don't
> understand is that
> we select SCHED_OTHER early on, before the xenomai shadow function is
> called, so
> Xenomai should have noticed it was SCHED_OTHER all along.
>
> So I would think that the rt_mutex_acquire(m, TM_NONBLOCK); is not noticed
> by Xenomai...
>
> We could test this with the above code and run with TM_NONBLOCK versus
> TM_INFINITE in the last rt_mutex_acquire. I would also suspect that the
> thread creation/joining code is irrelevant in this case.
>
> Peter
>
>
> Hi Peter,
>
>
> thank you for your remarks, it helps me with test case, now I have exactly
> the same behavior like OROCOS helloword example. What is really surprising
> is that the replacing TM_NONBLOCK with TM_INFINITE do magic and suppress
> signal generation. In my opinion it is not a case which Gilles mention. I
> think, that we should ask Gilles on Xenomai forum, I send a post?
>
Yes, now is a good time, especially with the surprising remark ! If
possible, attach the .c file instead of copy/pasting in into your email
program .
Cheers,
Peter