Task exit via rt_task_suspend()?

Task exit via rt_task_suspend()?

[Richard Weinberger]

Hi!

I have a not yet understood deadlock in a Xenomai application on my desk.
It looks like the deadlock is caused by the fact that rt_task_suspend()
can cause the calling thread to exit.

So, a thread puts itself into suspend and never returns (and exists).
Debugging indicates that ret = __RT(kill(pid, SIGSUSP)); in threadobj_suspend()
is the place where it enters the kernel and never return and inside the
kernel exits.

Can this be? :-S

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT
UID/VAT Nr: ATU 66964118 | FN: 374287y

Re: Task exit via rt_task_suspend()?

[Philippe Gerum]

Richard Weinberger <richard@sigma-star.at> writes:

> Hi!
>
> I have a not yet understood deadlock in a Xenomai application on my desk.
> It looks like the deadlock is caused by the fact that rt_task_suspend()
> can cause the calling thread to exit.
>
> So, a thread puts itself into suspend and never returns (and exists).
> Debugging indicates that ret = __RT(kill(pid, SIGSUSP)); in threadobj_suspend()
> is the place where it enters the kernel and never return and inside the
> kernel exits.
>
> Can this be? :-S
>
> Thanks,
> //richard

Cobalt signal handling may not be the cause of such exit, syscall
handling could be, i.e. any code path crossing xnthread_test_cancel()
starting from cobalt/posix/syscall.c. The best way to find out would be
ftracing.

-- 
Philippe.

Re: Task exit via rt_task_suspend()?

[Richard Weinberger]

Am Freitag, 18. August 2023, 19:26:15 CEST schrieb Philippe Gerum:
> 
> Richard Weinberger <richard@sigma-star.at> writes:
> 
> > Hi!
> >
> > I have a not yet understood deadlock in a Xenomai application on my desk.
> > It looks like the deadlock is caused by the fact that rt_task_suspend()
> > can cause the calling thread to exit.
> >
> > So, a thread puts itself into suspend and never returns (and exists).
> > Debugging indicates that ret = __RT(kill(pid, SIGSUSP)); in threadobj_suspend()
> > is the place where it enters the kernel and never return and inside the
> > kernel exits.
> >
> > Can this be? :-S
> >
> > Thanks,
> > //richard
> 
> Cobalt signal handling may not be the cause of such exit, syscall
> handling could be, i.e. any code path crossing xnthread_test_cancel()
> starting from cobalt/posix/syscall.c. The best way to find out would be
> ftracing.

Thanks for the info! I'm pretty sure XNCANCELD is not used.
I'll dig deeper.

Thanks,
//richard

-- 
​​​​​sigma star gmbh | Eduard-Bodem-Gasse 6, 6020 Innsbruck, AUT
UID/VAT Nr: ATU 66964118 | FN: 374287y