All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] signal handling in Xenomai 2.6.0
@ 2012-02-15 16:03 Jeff Webb
  2012-02-15 16:23 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 9+ messages in thread
From: Jeff Webb @ 2012-02-15 16:03 UTC (permalink / raw)
  To: Xenomai help

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

I am not able to block signals using pthread_sigmask or sigprocmask on my Xenomai 2.6.0 system.  If I compile my test program without Xenomai, it works as I intended and blocks the requested signals.  If I compile it for Xenomai, the requested signals are not blocked.  After scratching my head for some time, I tried running the program on an older machine running Xenomai 2.5.5.2, and it worked as I intended and blocked the requested signals.  I have not tried upgrading the Xenomai 2.5.5.2 machine to 2.6.0 to see if the problem is somehow related to the hardware on the newer machine.  I haven't noticed any other problems with Xenomai 2.6.0 on the newer machine; the latency and performance appear to be what I would expect.

My test program is attached.  I printed the current thread in the signal handler, and thought that the output might be of interest.  This is output from the program running under Xenomai 2.6.0:

   $ ./sigtest
   main thread: 7f6ff32c8700
   mlockall returned 0
   sigaction returned 0
   pthread_sigmask returned 0
   ^Csignal handled in: 7f6ff32f2700
   end of main
   $

If I comment out the call topthread_sigmask, I get this output:

   $ ./sigtest
   main thread: 7f446ba09700
   mlockall returned 0
   sigaction returned 0
   pthread_sigmask returned 0
   ^Csignal handled in: 7f446ba09700
   end of main
   $

It appears to me that in the first case, the signal is being blocked in the main thread, but is being handled in another (shadow?) thread.

Can someone confirm that this code works on Xenomai 2.6.0?

Thanks,

Jeff Webb


[-- Attachment #2: sigtest.c --]
[-- Type: text/x-csrc, Size: 879 bytes --]

#include <stdio.h>
#include <pthread.h>
#include <signal.h>
#include <sys/mman.h>

sig_atomic_t abort_program = 0;

void signal_handler(int sig)
{
  abort_program = 1;
  printf("signal handled in: %lx\n", pthread_self());
}

int main(void)
{
    int err;
    struct sigaction action;
    sigset_t mask;

    printf("main thread: %lx\n", pthread_self());

    err = mlockall(MCL_CURRENT | MCL_FUTURE);
    printf("mlockall returned %d\n", err);

    action.sa_handler = signal_handler;
    sigemptyset(&action.sa_mask);
    action.sa_flags = 0;
    err = sigaction(SIGINT, &action, NULL);
    printf("sigaction returned %d\n", err);
    
    sigemptyset(&mask);
    sigaddset(&mask, SIGINT);
    err = pthread_sigmask(SIG_BLOCK, &mask, NULL);
    printf("pthread_sigmask returned %d\n", err);    

    while(!abort_program)
    {}

    printf("end of main\n");
  
    return 0;
}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] signal handling in Xenomai 2.6.0
  2012-02-15 16:03 [Xenomai-help] signal handling in Xenomai 2.6.0 Jeff Webb
@ 2012-02-15 16:23 ` Gilles Chanteperdrix
  2012-02-15 17:23   ` Jeff Webb
  2012-02-23 22:02   ` [Xenomai-help] Real-time printf " Jeff Webb
  0 siblings, 2 replies; 9+ messages in thread
From: Gilles Chanteperdrix @ 2012-02-15 16:23 UTC (permalink / raw)
  To: Jeff Webb; +Cc: Xenomai help

On 02/15/2012 05:03 PM, Jeff Webb wrote:
> I am not able to block signals using pthread_sigmask or sigprocmask
> on my Xenomai 2.6.0 system.  If I compile my test program without
> Xenomai, it works as I intended and blocks the requested signals.  If
> I compile it for Xenomai, the requested signals are not blocked.
> After scratching my head for some time, I tried running the program
> on an older machine running Xenomai 2.5.5.2, and it worked as I
> intended and blocked the requested signals.  I have not tried
> upgrading the Xenomai 2.5.5.2 machine to 2.6.0 to see if the problem
> is somehow related to the hardware on the newer machine.  I haven't
> noticed any other problems with Xenomai 2.6.0 on the newer machine;
> the latency and performance appear to be what I would expect.
> 
> My test program is attached.  I printed the current thread in the
> signal handler, and thought that the output might be of interest.
> This is output from the program running under Xenomai 2.6.0:
> 
> $ ./sigtest main thread: 7f6ff32c8700 mlockall returned 0 sigaction
> returned 0 pthread_sigmask returned 0 ^Csignal handled in:
> 7f6ff32f2700 end of main $
> 
> If I comment out the call topthread_sigmask, I get this output:
> 
> $ ./sigtest main thread: 7f446ba09700 mlockall returned 0 sigaction
> returned 0 pthread_sigmask returned 0 ^Csignal handled in:
> 7f446ba09700 end of main $
> 
> It appears to me that in the first case, the signal is being blocked
> in the main thread, but is being handled in another (shadow?)
> thread.
> 
> Can someone confirm that this code works on Xenomai 2.6.0?

Please try the following patch:

diff --git a/src/skins/common/rt_print.c b/src/skins/common/rt_print.c
index 5533e29..78dcda8 100644
--- a/src/skins/common/rt_print.c
+++ b/src/skins/common/rt_print.c
@@ -612,6 +612,11 @@ static void unlock(void *cookie)

 static void *printer_loop(void *arg)
 {
+	sigset_t mask;
+
+	sigfillset(&mask);
+	pthread_sigmask(SIG_BLOCK, &mask, NULL);
+
 	while (1) {
 		pthread_cleanup_push(unlock, &buffer_lock);
 		pthread_mutex_lock(&buffer_lock);


-- 
					    Gilles.


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] signal handling in Xenomai 2.6.0
  2012-02-15 16:23 ` Gilles Chanteperdrix
@ 2012-02-15 17:23   ` Jeff Webb
  2012-02-23 22:02   ` [Xenomai-help] Real-time printf " Jeff Webb
  1 sibling, 0 replies; 9+ messages in thread
From: Jeff Webb @ 2012-02-15 17:23 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: Xenomai help

On 02/15/2012 10:23 AM, Gilles Chanteperdrix wrote:
> On 02/15/2012 05:03 PM, Jeff Webb wrote:
>> I am not able to block signals using pthread_sigmask or sigprocmask
>> on my Xenomai 2.6.0 system.  If I compile my test program without
>> Xenomai, it works as I intended and blocks the requested signals.  If
>> I compile it for Xenomai, the requested signals are not blocked.
>>...
>> Can someone confirm that this code works on Xenomai 2.6.0?
>
> Please try the following patch:
> ...

Thanks, Gilles.  That seems to have fixed the problem.  I had to add "#include <signal.h>" at the top of rt_print.c to get your patched version to compile.   I just rebuilt my userspace packages, not the kernel.

Thanks again for the quick response.

-Jeff


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-02-15 16:23 ` Gilles Chanteperdrix
  2012-02-15 17:23   ` Jeff Webb
@ 2012-02-23 22:02   ` Jeff Webb
  2012-02-23 22:26     ` Gilles Chanteperdrix
  1 sibling, 1 reply; 9+ messages in thread
From: Jeff Webb @ 2012-02-23 22:02 UTC (permalink / raw)
  To: Xenomai help

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

I was happy to see that printf now works from real-time POSIX threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange behavior that surfaces when I try to print the string "\n" by itself.  When I run the attached example program, I get:

   $ ./printf_test
   start
   CPU time limit exceeded
   $

IfI replace the two printf calls with rt_printf calls and #include <rtdk.h>,I get the expected result:

   $ ./rt_printf_test
   start
   1
   2
   3
   4
   ^C
   $

The original example also works if these two lines:

         printf("%d", count);
         printf("\n");

are replaced with:

         printf("%d\n", count);

Can someone confirm if this a bug in Xenomai 2.6.0, something specific to my HW/SW installation, or some mistake in my test program?

Thanks,

Jeff

[-- Attachment #2: printf_test.c --]
[-- Type: text/x-csrc, Size: 1028 bytes --]

#include <stdio.h>
#include <pthread.h>
#include <sys/mman.h>
#include <malloc.h>

int count = 0;

void * rt_loop(void * arg)
{
    struct timespec dt_ts;
    dt_ts.tv_sec  = 1;
    dt_ts.tv_nsec = 0;    

    pthread_set_mode_np(0, PTHREAD_WARNSW);

    printf("start\n");

    while (1)
    {
        count++;
        clock_nanosleep(CLOCK_REALTIME, 0, &dt_ts, NULL);
        printf("%d", count);
        printf("\n");
    }
    
    return NULL;
}

int main(void)
{
    pthread_attr_t attr;
    pthread_t rt_thread;
    struct sched_param sparam;
  
    mlockall(MCL_CURRENT | MCL_FUTURE);

    sparam.sched_priority = 16;

    pthread_attr_init(&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_JOINABLE);
    pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
    pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
    pthread_attr_setschedparam(&attr, &sparam);
    pthread_create(&rt_thread, &attr, &rt_loop, NULL);
    pthread_attr_destroy(&attr);

    pthread_join(rt_thread, NULL);

    return 0;
}

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-02-23 22:02   ` [Xenomai-help] Real-time printf " Jeff Webb
@ 2012-02-23 22:26     ` Gilles Chanteperdrix
  2012-02-23 23:07       ` Jeff Webb
  0 siblings, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2012-02-23 22:26 UTC (permalink / raw)
  To: Jeff Webb; +Cc: Xenomai help

On 02/23/2012 11:02 PM, Jeff Webb wrote:
> I was happy to see that printf now works from real-time POSIX threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange behavior that surfaces when I try to print the string "\n" by itself.  When I run the attached example program, I get:
> 
>    $ ./printf_test
>    start
>    CPU time limit exceeded
>    $
> 
> IfI replace the two printf calls with rt_printf calls and #include <rtdk.h>,I get the expected result:
> 
>    $ ./rt_printf_test
>    start
>    1
>    2
>    3
>    4
>    ^C
>    $
> 
> The original example also works if these two lines:
> 
>          printf("%d", count);
>          printf("\n");
> 
> are replaced with:
> 
>          printf("%d\n", count);
> 
> Can someone confirm if this a bug in Xenomai 2.6.0, something specific to my HW/SW installation, or some mistake in my test program?

I would bet the call to printf is replaced with something else (such as
putchar). Could you disassemble the test to check this?

Note that I have fixed similar issues in xenomai-2.6 current repository,
so you could give it a try.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-02-23 22:26     ` Gilles Chanteperdrix
@ 2012-02-23 23:07       ` Jeff Webb
  2012-02-23 23:14         ` Gilles Chanteperdrix
  2012-04-15 17:42         ` Gilles Chanteperdrix
  0 siblings, 2 replies; 9+ messages in thread
From: Jeff Webb @ 2012-02-23 23:07 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: Xenomai help

On 02/23/2012 04:26 PM, Gilles Chanteperdrix wrote:
> On 02/23/2012 11:02 PM, Jeff Webb wrote:
>> I was happy to see that printf now works from real-time POSIX threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange behavior that surfaces when I try to print the string "\n" by itself.  When I run the attached example program, I get:
>>
>>     $ ./printf_test
>>     start
>>     CPU time limit exceeded
>>     $
>>
>> IfI replace the two printf calls with rt_printf calls and #include<rtdk.h>,I get the expected result:
>>
>>     $ ./rt_printf_test
>>     start
>>     1
>>     2
>>     3
>>     4
>>     ^C
>>     $
>>
>> The original example also works if these two lines:
>>
>>           printf("%d", count);
>>           printf("\n");
>>
>> are replaced with:
>>
>>           printf("%d\n", count);
>>
>> Can someone confirm if this a bug in Xenomai 2.6.0, something specific to my HW/SW installation, or some mistake in my test program?
>
> I would bet the call to printf is replaced with something else (such as
> putchar). Could you disassemble the test to check this?

Yes, it appears that putchar is called indeed.

> Note that I have fixed similar issues in xenomai-2.6 current repository,
> so you could give it a try.

I may give that a try.  Now that I have confirmed that putchar is the issue, do you think xenomai-2.6 current will fix the problem?  Is putchar now wrapped as well?  I noticed that puts appears to be wrapped from the disassembly output.

Thanks again for all the help,

Jeff


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-02-23 23:07       ` Jeff Webb
@ 2012-02-23 23:14         ` Gilles Chanteperdrix
  2012-04-15 17:42         ` Gilles Chanteperdrix
  1 sibling, 0 replies; 9+ messages in thread
From: Gilles Chanteperdrix @ 2012-02-23 23:14 UTC (permalink / raw)
  To: Jeff Webb; +Cc: Xenomai help

On 02/24/2012 12:07 AM, Jeff Webb wrote:
> On 02/23/2012 04:26 PM, Gilles Chanteperdrix wrote:
>> On 02/23/2012 11:02 PM, Jeff Webb wrote:
>>> I was happy to see that printf now works from real-time POSIX
>>> threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange
>>> behavior that surfaces when I try to print the string "\n" by
>>> itself.  When I run the attached example program, I get:
>>> 
>>> $ ./printf_test start CPU time limit exceeded $
>>> 
>>> IfI replace the two printf calls with rt_printf calls and
>>> #include<rtdk.h>,I get the expected result:
>>> 
>>> $ ./rt_printf_test start 1 2 3 4 ^C $
>>> 
>>> The original example also works if these two lines:
>>> 
>>> printf("%d", count); printf("\n");
>>> 
>>> are replaced with:
>>> 
>>> printf("%d\n", count);
>>> 
>>> Can someone confirm if this a bug in Xenomai 2.6.0, something
>>> specific to my HW/SW installation, or some mistake in my test
>>> program?
>> 
>> I would bet the call to printf is replaced with something else
>> (such as putchar). Could you disassemble the test to check this?
> 
> Yes, it appears that putchar is called indeed.
> 
>> Note that I have fixed similar issues in xenomai-2.6 current
>> repository, so you could give it a try.
> 
> I may give that a try.  Now that I have confirmed that putchar is the
> issue, do you think xenomai-2.6 current will fix the problem?  Is
> putchar now wrapped as well?  I noticed that puts appears to be
> wrapped from the disassembly output.

No, it is not yet wrapped.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-02-23 23:07       ` Jeff Webb
  2012-02-23 23:14         ` Gilles Chanteperdrix
@ 2012-04-15 17:42         ` Gilles Chanteperdrix
  2012-04-17 22:22           ` Jeff Webb
  1 sibling, 1 reply; 9+ messages in thread
From: Gilles Chanteperdrix @ 2012-04-15 17:42 UTC (permalink / raw)
  To: Jeff Webb; +Cc: Xenomai help

On 02/24/2012 12:07 AM, Jeff Webb wrote:
> On 02/23/2012 04:26 PM, Gilles Chanteperdrix wrote:
>> On 02/23/2012 11:02 PM, Jeff Webb wrote:
>>> I was happy to see that printf now works from real-time POSIX
>>> threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange
>>> behavior that surfaces when I try to print the string "\n" by
>>> itself.  When I run the attached example program, I get:
>>> 
>>> $ ./printf_test start CPU time limit exceeded $
>>> 
>>> IfI replace the two printf calls with rt_printf calls and
>>> #include<rtdk.h>,I get the expected result:
>>> 
>>> $ ./rt_printf_test start 1 2 3 4 ^C $
>>> 
>>> The original example also works if these two lines:
>>> 
>>> printf("%d", count); printf("\n");
>>> 
>>> are replaced with:
>>> 
>>> printf("%d\n", count);
>>> 
>>> Can someone confirm if this a bug in Xenomai 2.6.0, something
>>> specific to my HW/SW installation, or some mistake in my test
>>> program?
>> 
>> I would bet the call to printf is replaced with something else
>> (such as putchar). Could you disassemble the test to check this?
> 
> Yes, it appears that putchar is called indeed.
> 
>> Note that I have fixed similar issues in xenomai-2.6 current
>> repository, so you could give it a try.
> 
> I may give that a try.  Now that I have confirmed that putchar is the
> issue, do you think xenomai-2.6 current will fix the problem?  Is
> putchar now wrapped as well?  I noticed that puts appears to be
> wrapped from the disassembly output.

It should now be fixed in xenomai-2.6 repository.

-- 
                                                                Gilles.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Xenomai-help] Real-time printf in Xenomai 2.6.0
  2012-04-15 17:42         ` Gilles Chanteperdrix
@ 2012-04-17 22:22           ` Jeff Webb
  0 siblings, 0 replies; 9+ messages in thread
From: Jeff Webb @ 2012-04-17 22:22 UTC (permalink / raw)
  To: Gilles Chanteperdrix; +Cc: Xenomai help

On 04/15/2012 12:42 PM, Gilles Chanteperdrix wrote:
> On 02/24/2012 12:07 AM, Jeff Webb wrote:
>> On 02/23/2012 04:26 PM, Gilles Chanteperdrix wrote:
>>> On 02/23/2012 11:02 PM, Jeff Webb wrote:
>>>> I was happy to see that printf now works from real-time POSIX
>>>> threads in Xenomai 2.6.0.  Unfortunately, I'm seeing some strange
>>>> behavior that surfaces when I try to print the string "\n" by
>>>> itself.  When I run the attached example program, I get:
>>>>
>>>> $ ./printf_test start CPU time limit exceeded $
>>>>
>>>> IfI replace the two printf calls with rt_printf calls and
>>>> #include<rtdk.h>,I get the expected result:
>>>>
>>>> $ ./rt_printf_test start 1 2 3 4 ^C $
>>>>
>>>> The original example also works if these two lines:
>>>>
>>>> printf("%d", count); printf("\n");
>>>>
>>>> are replaced with:
>>>>
>>>> printf("%d\n", count);
>>>>
>>>> Can someone confirm if this a bug in Xenomai 2.6.0, something
>>>> specific to my HW/SW installation, or some mistake in my test
>>>> program?
>>>
>>> I would bet the call to printf is replaced with something else
>>> (such as putchar). Could you disassemble the test to check this?
>>
>> Yes, it appears that putchar is called indeed.
>>
>>> Note that I have fixed similar issues in xenomai-2.6 current
>>> repository, so you could give it a try.
>>
>> I may give that a try.  Now that I have confirmed that putchar is the
>> issue, do you think xenomai-2.6 current will fix the problem?  Is
>> putchar now wrapped as well?  I noticed that puts appears to be
>> wrapped from the disassembly output.
>
> It should now be fixed in xenomai-2.6 repository.
>

Thanks for following up, Gilles.

-Jeff


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-04-17 22:22 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-15 16:03 [Xenomai-help] signal handling in Xenomai 2.6.0 Jeff Webb
2012-02-15 16:23 ` Gilles Chanteperdrix
2012-02-15 17:23   ` Jeff Webb
2012-02-23 22:02   ` [Xenomai-help] Real-time printf " Jeff Webb
2012-02-23 22:26     ` Gilles Chanteperdrix
2012-02-23 23:07       ` Jeff Webb
2012-02-23 23:14         ` Gilles Chanteperdrix
2012-04-15 17:42         ` Gilles Chanteperdrix
2012-04-17 22:22           ` Jeff Webb

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.