* [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
@ 2013-09-13 20:48 Daniel Merrill
2013-09-13 20:54 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Merrill @ 2013-09-13 20:48 UTC (permalink / raw)
To: xenomai
All,
I'm running into an issue I'm having trouble explaining. I'm hoping you
all will be able to clear it up for me. From my understanding of psos
(which could be wrong) I should be able to call t_delete from either
myself or another task. However, in the xenomai implementation it only
works if I call it from the original "main" thread. If I create two tasks
and one calls t_delete on the other I get a SIGSEGV and the application
dies. Can anyone explain if this is intended behavior and maybe I'm just
not doing it correctly, or possibly a bug in t_delete? Any and all help is
appreciated. I'm using xenomai 2.6.2.1 and Linux 3.5.7. If there are more
details needed I will gladly provide them. TIA.
Here is an example app that demonstrates the issue I'm seeing.
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
#include <psos.h>
void suspended_task()
{
printf("Suspending myself\n");
t_suspend(0);
}
void deleter(u_long targs[])
{
tm_wkafter(1000);
t_delete(targs[0]);
t_suspend(0);
}
void main()
{
mlockall(MCL_CURRENT | MCL_FUTURE);
u_long TID, TID2;
u_long args[4] = {TID, 0, 0, 0};
u_long Status = 0;
t_create("TSK1", 55, 10000, 0, T_LOCAL | T_NOFPU, &TID);
t_start(TID, T_PREEMPT | T_TSLICE, &suspended_task, NULL);
t_create("TSK2", 56, 10000, 0, T_LOCAL | T_NOFPU, &TID2);
t_start(TID2, T_PREEMPT | T_TSLICE, &deleter, args);
tm_wkafter(1000);
// Status = t_delete(TID);
// printf("Status of Delete is %lu\n", Status);
while(1)
tm_wkafter(5000);
}
Regards,
Dan Merrill
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
2013-09-13 20:48 [Xenomai] psos t_delete causing a SIGSEGV in suspended task Daniel Merrill
@ 2013-09-13 20:54 ` Gilles Chanteperdrix
[not found] ` <fcac2f91.00001e70.00000001@dmerrill_win764.PERF.PERFORMANCESOFTWARE>
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-09-13 20:54 UTC (permalink / raw)
To: Daniel Merrill; +Cc: xenomai
On 09/13/2013 10:48 PM, Daniel Merrill wrote:
> void main()
>
> {
>
> mlockall(MCL_CURRENT | MCL_FUTURE);
>
> u_long TID, TID2;
>
> u_long args[4] = {TID, 0, 0, 0};
TID here is an uninitialized value, and this is what you pass to
t_delete. I admit the segmentation does not seem like the best reaction,
but the program looks faulty.
> (...)
> t_start(TID2, T_PREEMPT | T_TSLICE, &deleter, args);
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
[not found] ` <fcac2f91.00001e70.00000001@dmerrill_win764.PERF.PERFORMANCESOFTWARE>
@ 2013-09-13 21:45 ` Daniel Merrill
2013-09-13 21:47 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Merrill @ 2013-09-13 21:45 UTC (permalink / raw)
To: 'Gilles Chanteperdrix'; +Cc: xenomai
Ok, good catch :) that was a stupid mistake I made while trying to condense
the problem down to a more manageable size. Which apparently when I do it
works, so I'm obviously not understanding the real issue here. So much for
trying to look smart. How about a stack trace from the real issue.
#0 0xb7d474f6 in __gnat_is_handled_by_others ()
from /usr/lib/i386-linux-gnu/libgnat-4.6.so.1
#1 0xb7ec4822 in __gnat_personality_v0 () from
/usr/lib/i386-linux-gnu/libgnat-4.6.so.1
#2 0xb7c65056 in ?? () from /lib/i386-linux-gnu/libgcc_s.so.1
#3 0xb7c65448 in _Unwind_ForcedUnwind () from
/lib/i386-linux-gnu/libgcc_s.so.1
#4 0xb7f788c2 in _Unwind_ForcedUnwind () from
/lib/i386-linux-gnu/libpthread.so.0
#5 0xb7f76381 in __pthread_unwind () from
/lib/i386-linux-gnu/libpthread.so.0
#6 0xb7f6e5eb in sigcancel_handler () from
/lib/i386-linux-gnu/libpthread.so.0
#7 <signal handler called>
#8 0xb7fdd424 in __kernel_vsyscall ()
#9 0xb7fd7541 in t_suspend () from /usr/lib/libpsos.so.0
As soon as we call t_delete on the suspended task, we see this issue popping
up. Any ideas?
-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Sent: Friday, September 13, 2013 1:55 PM
To: Daniel Merrill
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
On 09/13/2013 10:48 PM, Daniel Merrill wrote:
> void main()
>
> {
>
> mlockall(MCL_CURRENT | MCL_FUTURE);
>
> u_long TID, TID2;
>
> u_long args[4] = {TID, 0, 0, 0};
TID here is an uninitialized value, and this is what you pass to t_delete. I
admit the segmentation does not seem like the best reaction, but the program
looks faulty.
> (...)
> t_start(TID2, T_PREEMPT | T_TSLICE, &deleter, args);
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
2013-09-13 21:45 ` Daniel Merrill
@ 2013-09-13 21:47 ` Gilles Chanteperdrix
2013-09-13 23:23 ` Daniel Merrill
0 siblings, 1 reply; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-09-13 21:47 UTC (permalink / raw)
To: Daniel Merrill; +Cc: xenomai
On 09/13/2013 11:45 PM, Daniel Merrill wrote:
> Ok, good catch :) that was a stupid mistake I made while trying to condense
> the problem down to a more manageable size. Which apparently when I do it
> works, so I'm obviously not understanding the real issue here. So much for
> trying to look smart. How about a stack trace from the real issue.
>
> #0 0xb7d474f6 in __gnat_is_handled_by_others ()
> from /usr/lib/i386-linux-gnu/libgnat-4.6.so.1
> #1 0xb7ec4822 in __gnat_personality_v0 () from
> /usr/lib/i386-linux-gnu/libgnat-4.6.so.1
> #2 0xb7c65056 in ?? () from /lib/i386-linux-gnu/libgcc_s.so.1
> #3 0xb7c65448 in _Unwind_ForcedUnwind () from
> /lib/i386-linux-gnu/libgcc_s.so.1
> #4 0xb7f788c2 in _Unwind_ForcedUnwind () from
> /lib/i386-linux-gnu/libpthread.so.0
> #5 0xb7f76381 in __pthread_unwind () from
> /lib/i386-linux-gnu/libpthread.so.0
> #6 0xb7f6e5eb in sigcancel_handler () from
> /lib/i386-linux-gnu/libpthread.so.0
> #7 <signal handler called>
> #8 0xb7fdd424 in __kernel_vsyscall ()
> #9 0xb7fd7541 in t_suspend () from /usr/lib/libpsos.so.0
>
> As soon as we call t_delete on the suspended task, we see this issue popping
> up. Any ideas?
Well, the program goes south when trying to unwind after pthread_cancel.
Maybe C++ code compiled with -fno-exceptions ?
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
2013-09-13 21:47 ` Gilles Chanteperdrix
@ 2013-09-13 23:23 ` Daniel Merrill
2013-09-14 13:47 ` Gilles Chanteperdrix
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Merrill @ 2013-09-13 23:23 UTC (permalink / raw)
To: 'Gilles Chanteperdrix'; +Cc: xenomai
-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
Sent: Friday, September 13, 2013 2:48 PM
To: Daniel Merrill
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
On 09/13/2013 11:45 PM, Daniel Merrill wrote:
> Ok, good catch :) that was a stupid mistake I made while trying to
> condense the problem down to a more manageable size. Which apparently
> when I do it works, so I'm obviously not understanding the real issue
> here. So much for trying to look smart. How about a stack trace from the
> real issue.
>
> #0 0xb7d474f6 in __gnat_is_handled_by_others ()
> from /usr/lib/i386-linux-gnu/libgnat-4.6.so.1
> #1 0xb7ec4822 in __gnat_personality_v0 () from
> /usr/lib/i386-linux-gnu/libgnat-4.6.so.1
> #2 0xb7c65056 in ?? () from /lib/i386-linux-gnu/libgcc_s.so.1
> #3 0xb7c65448 in _Unwind_ForcedUnwind () from
> /lib/i386-linux-gnu/libgcc_s.so.1
> #4 0xb7f788c2 in _Unwind_ForcedUnwind () from
> /lib/i386-linux-gnu/libpthread.so.0
> #5 0xb7f76381 in __pthread_unwind () from
> /lib/i386-linux-gnu/libpthread.so.0
> #6 0xb7f6e5eb in sigcancel_handler () from
> /lib/i386-linux-gnu/libpthread.so.0
> #7 <signal handler called>
> #8 0xb7fdd424 in __kernel_vsyscall ()
> #9 0xb7fd7541 in t_suspend () from /usr/lib/libpsos.so.0
>
> As soon as we call t_delete on the suspended task, we see this issue
> popping up. Any ideas?
Well, the program goes south when trying to unwind after pthread_cancel.
Maybe C++ code compiled with -fno-exceptions ?
--
Gilles.
Alright I think you solved it! We are actually calling the t_suspend from
Ada, which had an exception block around the call. For some reason that is
trying to catch the cancel signal and causes the SIGSEGV. When I remove that
exception handling block the delete appears to work. Thanks for pointing me
in the right direction.
Dan Merrill
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai] psos t_delete causing a SIGSEGV in suspended task.
2013-09-13 23:23 ` Daniel Merrill
@ 2013-09-14 13:47 ` Gilles Chanteperdrix
0 siblings, 0 replies; 6+ messages in thread
From: Gilles Chanteperdrix @ 2013-09-14 13:47 UTC (permalink / raw)
To: Daniel Merrill; +Cc: xenomai
On 09/14/2013 01:23 AM, Daniel Merrill wrote:
> Alright I think you solved it! We are actually calling the t_suspend from
> Ada, which had an exception block around the call. For some reason that is
> trying to catch the cancel signal and causes the SIGSEGV. When I remove that
> exception handling block the delete appears to work. Thanks for pointing me
> in the right direction.
>From what I understand, unwinding on pthread_cancel is a feature which
allows automatic destruction of all the objects created on the thread
stack in C++ (and other languages implementing exceptions apparently)
upon pthread_cancel, this way, pthread_cleanup_push and pthread_cleanup
pop are simply handled as C++ objects constructors/destructors when used
in C++ code.
--
Gilles.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-09-14 13:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-13 20:48 [Xenomai] psos t_delete causing a SIGSEGV in suspended task Daniel Merrill
2013-09-13 20:54 ` Gilles Chanteperdrix
[not found] ` <fcac2f91.00001e70.00000001@dmerrill_win764.PERF.PERFORMANCESOFTWARE>
2013-09-13 21:45 ` Daniel Merrill
2013-09-13 21:47 ` Gilles Chanteperdrix
2013-09-13 23:23 ` Daniel Merrill
2013-09-14 13:47 ` Gilles Chanteperdrix
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.