[Xenomai-help] Correct use of xeno_sigshadow_install()

[Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

Hi,

A while ago, I was advised to call xeno_sigshadow_install() after a library 
installed a sigwinch signal handler (I believe this was Xenomai 2.5.1). Could 
it be that this is no longer supported in recent versions ? What is the 
correct way to avoid a segfault if an application installed a sigwinch handler 
after Xenomai did ?

Regards,
Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> Hi,
> 
> A while ago, I was advised to call xeno_sigshadow_install() after a library 
> installed a sigwinch signal handler (I believe this was Xenomai 2.5.1). Could 
> it be that this is no longer supported in recent versions ? What is the 
> correct way to avoid a segfault if an application installed a sigwinch handler 
> after Xenomai did ?

I think we already answered that at the time, but if you install your
own sigwinch handler, you should:
- register it with the SA_SIGINFO flag
- call xeno_sigwinch_handler and consider that the signal is for the
application only if this function returns 0.

If you can not do that, then redefine SIGSHADOW in
include/asm-generic/syscall.h to a different value, and recompile both
Xenomai user-space and kernel-space support. Note however that when
starting applications in gdb you will then have to type:

handle <the_new_signal> pass nostop print

If you want to be able to debug Xenomai applications.

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> Hi,
> 
> A while ago, I was advised to call xeno_sigshadow_install() after a library 
> installed a sigwinch signal handler (I believe this was Xenomai 2.5.1). Could 
> it be that this is no longer supported in recent versions ? What is the 
> correct way to avoid a segfault if an application installed a sigwinch handler 
> after Xenomai did ?

In fact, I am not sure I understand your question. Could you post a
simple example having this issue?

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > Hi,
> > 
> > A while ago, I was advised to call xeno_sigshadow_install() after a
> > library installed a sigwinch signal handler (I believe this was Xenomai
> > 2.5.1). Could it be that this is no longer supported in recent versions
> > ? What is the correct way to avoid a segfault if an application
> > installed a sigwinch handler after Xenomai did ?
> 
> I think we already answered that at the time, but if you install your
> own sigwinch handler, you should:
> - register it with the SA_SIGINFO flag
> - call xeno_sigwinch_handler and consider that the signal is for the
> application only if this function returns 0.

This is indeed in the API docs, but it's not an option since it's a third 
party library (readline) doing this, it doesn't depend on or know Xenomai.

> 
> If you can not do that, then redefine SIGSHADOW in
> include/asm-generic/syscall.h to a different value, and recompile both
> Xenomai user-space and kernel-space support. Note however that when
> starting applications in gdb you will then have to type:
> 
> handle <the_new_signal> pass nostop print
> 
> If you want to be able to debug Xenomai applications.

Hmm....

So defining the xeno_sigshadow_install() function ourselves (since it's not in 
any Xenomai header) and calling it after the readline signal handlers were 
installed is not gonna work ?

Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
>> Peter Soetens wrote:
>>> Hi,
>>>
>>> A while ago, I was advised to call xeno_sigshadow_install() after a
>>> library installed a sigwinch signal handler (I believe this was Xenomai
>>> 2.5.1). Could it be that this is no longer supported in recent versions
>>> ? What is the correct way to avoid a segfault if an application
>>> installed a sigwinch handler after Xenomai did ?
>> I think we already answered that at the time, but if you install your
>> own sigwinch handler, you should:
>> - register it with the SA_SIGINFO flag
>> - call xeno_sigwinch_handler and consider that the signal is for the
>> application only if this function returns 0.
> 
> This is indeed in the API docs, but it's not an option since it's a third 
> party library (readline) doing this, it doesn't depend on or know Xenomai.
> 
>> If you can not do that, then redefine SIGSHADOW in
>> include/asm-generic/syscall.h to a different value, and recompile both
>> Xenomai user-space and kernel-space support. Note however that when
>> starting applications in gdb you will then have to type:
>>
>> handle <the_new_signal> pass nostop print
>>
>> If you want to be able to debug Xenomai applications.
> 
> Hmm....
> 
> So defining the xeno_sigshadow_install() function ourselves (since it's not in 
> any Xenomai header) and calling it after the readline signal handlers were 
> installed is not gonna work ?

The thing is that xeno_sigshadow_installi is an internal function,
particularily, it is not thread safe. The exported function is
xeno_sigshadow_install_once, but it will not do anything the second time
it gets called.

If you take care of this thread-safety issue, calling
xeno_sigshadow_install should be OK, since it just installs
xeno_sigshadow_handler as a handler for SIGSHADOW, calling
xeno_sigwinch_handler, then the handler your application registered
before. All this code is relatively simple, and you will find it in
src/skins/common/sigshadow.c

Now, I suspect the issue you have is something else, so, could you post
the faulting code, reduced to a simple self-contained test case?

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
>> Peter Soetens wrote:
>>> Hi,
>>>
>>> A while ago, I was advised to call xeno_sigshadow_install() after a
>>> library installed a sigwinch signal handler (I believe this was Xenomai
>>> 2.5.1). Could it be that this is no longer supported in recent versions
>>> ? What is the correct way to avoid a segfault if an application
>>> installed a sigwinch handler after Xenomai did ?
>> I think we already answered that at the time, but if you install your
>> own sigwinch handler, you should:
>> - register it with the SA_SIGINFO flag
>> - call xeno_sigwinch_handler and consider that the signal is for the
>> application only if this function returns 0.
> 
> This is indeed in the API docs, but it's not an option since it's a third 
> party library (readline) doing this, it doesn't depend on or know Xenomai.

Actually, readline behaviour is highly configurable, and looking a bit
at its documentation, we find that its behaviour with regard to sigwinch
is configurable, see:
rl_catch_sigwinch
rl_resize_terminal

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

On Monday 10 January 2011 19:25:48 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> >> Peter Soetens wrote:
> >>> Hi,
> >>> 
> >>> A while ago, I was advised to call xeno_sigshadow_install() after a
> >>> library installed a sigwinch signal handler (I believe this was Xenomai
> >>> 2.5.1). Could it be that this is no longer supported in recent versions
> >>> ? What is the correct way to avoid a segfault if an application
> >>> installed a sigwinch handler after Xenomai did ?
> >> 
> >> I think we already answered that at the time, but if you install your
> >> own sigwinch handler, you should:
> >> - register it with the SA_SIGINFO flag
> >> - call xeno_sigwinch_handler and consider that the signal is for the
> >> application only if this function returns 0.
> > 
> > This is indeed in the API docs, but it's not an option since it's a third
> > party library (readline) doing this, it doesn't depend on or know
> > Xenomai.
> 
> Actually, readline behaviour is highly configurable, and looking a bit
> at its documentation, we find that its behaviour with regard to sigwinch
> is configurable, see:
> rl_catch_sigwinch
> rl_resize_terminal

But we *want* to catch sigwinch/resize_terminal, since this happens quite 
often. Without this signal the terminal width is not being communicated to the 
readline library and it displays its columns in a too large or too small 
width.

It's the terminal emulator giving us this signal, and it is meaningful to us. 
It's Xenomai doing something fundamentally flawed, or I fundamentally 
misunderstand it. Why can't you register a signal handler, without interfering 
with other handlers for the same signal ?

Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Monday 10 January 2011 19:25:48 Gilles Chanteperdrix wrote:
>> Peter Soetens wrote:
>>> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
>>>> Peter Soetens wrote:
>>>>> Hi,
>>>>>
>>>>> A while ago, I was advised to call xeno_sigshadow_install() after a
>>>>> library installed a sigwinch signal handler (I believe this was Xenomai
>>>>> 2.5.1). Could it be that this is no longer supported in recent versions
>>>>> ? What is the correct way to avoid a segfault if an application
>>>>> installed a sigwinch handler after Xenomai did ?
>>>> I think we already answered that at the time, but if you install your
>>>> own sigwinch handler, you should:
>>>> - register it with the SA_SIGINFO flag
>>>> - call xeno_sigwinch_handler and consider that the signal is for the
>>>> application only if this function returns 0.
>>> This is indeed in the API docs, but it's not an option since it's a third
>>> party library (readline) doing this, it doesn't depend on or know
>>> Xenomai.
>> Actually, readline behaviour is highly configurable, and looking a bit
>> at its documentation, we find that its behaviour with regard to sigwinch
>> is configurable, see:
>> rl_catch_sigwinch
>> rl_resize_terminal
> 
> But we *want* to catch sigwinch/resize_terminal, since this happens quite 
> often. Without this signal the terminal width is not being communicated to the 
> readline library and it displays its columns in a too large or too small 
> width.
> 
> It's the terminal emulator giving us this signal, and it is meaningful to us. 
> It's Xenomai doing something fundamentally flawed, or I fundamentally 
> misunderstand it. 

Look at the documentation of rl_catch_sigwinch, rl_resize_terminal, they
have been made precisely, for your use-case. rl_catch_sigwinch will get
readline not to catch the signal.

Then you will register a signal handler for your application, which
calls, xeno_sigwinch_handler, and if that returns zero, calls
rl_resize_terminal.

> Why can't you register a signal handler, without interfering 
> with other handlers for the same signal ?

Well, signal handlers are a per-process global ressource, look at
sigaction documentation, this API is done this way, this is not
Xenomai's fault, not even Linux' fault, you are barking at the wrong
tree. That is precisely the reason why readline gives you access to
rl_catch_sigwinch, rl_resize_terminal, and Xenomai to xeno_sigwinch_handler.

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

On Monday 10 January 2011 17:50:05 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> >> Peter Soetens wrote:
> >>> Hi,
> >>> 
> >>> A while ago, I was advised to call xeno_sigshadow_install() after a
> >>> library installed a sigwinch signal handler (I believe this was Xenomai
> >>> 2.5.1). Could it be that this is no longer supported in recent versions
> >>> ? What is the correct way to avoid a segfault if an application
> >>> installed a sigwinch handler after Xenomai did ?
> >> 
> >> I think we already answered that at the time, but if you install your
> >> own sigwinch handler, you should:
> >> - register it with the SA_SIGINFO flag
> >> - call xeno_sigwinch_handler and consider that the signal is for the
> >> application only if this function returns 0.
> > 
> > This is indeed in the API docs, but it's not an option since it's a third
> > party library (readline) doing this, it doesn't depend on or know
> > Xenomai.
> > 
> >> If you can not do that, then redefine SIGSHADOW in
> >> include/asm-generic/syscall.h to a different value, and recompile both
> >> Xenomai user-space and kernel-space support. Note however that when
> >> starting applications in gdb you will then have to type:
> >> 
> >> handle <the_new_signal> pass nostop print
> >> 
> >> If you want to be able to debug Xenomai applications.
> > 
> > Hmm....
> > 
> > So defining the xeno_sigshadow_install() function ourselves (since it's
> > not in any Xenomai header) and calling it after the readline signal
> > handlers were installed is not gonna work ?
> 
> The thing is that xeno_sigshadow_installi is an internal function,
> particularily, it is not thread safe. The exported function is
> xeno_sigshadow_install_once, but it will not do anything the second time
> it gets called.
> 
> If you take care of this thread-safety issue, calling
> xeno_sigshadow_install should be OK, since it just installs
> xeno_sigshadow_handler as a handler for SIGSHADOW, calling
> xeno_sigwinch_handler, then the handler your application registered
> before. All this code is relatively simple, and you will find it in
> src/skins/common/sigshadow.c
> 
> Now, I suspect the issue you have is something else, so, could you post
> the faulting code, reduced to a simple self-contained test case?

main.cpp:
#include <readline/readline.h>
#include <readline/history.h>
#include <xenomai/native/task.h>
#include <malloc.h>
#include <sys/mman.h>
#include <stdio.h>

char* line_read = 0;

char *rl_gets ()
{
  /* If the buffer has already been allocated,                                                                                                                                                                 
     return the memory to the free pool. */
  if (line_read)
    {
      free (line_read);
      line_read = 0;
    }

  if (rl_set_signals() != 0)
    printf("Error setting signals !\n");

  line_read = readline ( ">" );

  /* If the line has any text in it,                                                                                                                                                                           
     save it on the history. */
  if (line_read && *line_read) {
    add_history (line_read);
  }
  return (line_read);
}

int main(void)
{
  mlockall(MCL_CURRENT | MCL_FUTURE);

  RT_TASK xenotask;
  rt_task_shadow( &(xenotask),0, 10, 0);
  rl_completion_append_character = '\0'; // avoid adding spaces                                                                                                                                                

  if ( read_history(".history") != 0 ) {
    read_history("~/.history");
  }

  // Let readline intercept relevant signals                                                                                                                                                                   
  if(rl_catch_signals == 0)
    printf("Error catching signals !\n");

  if (rl_set_signals() != 0)
    printf("Error setting signals !\n");

  while (1)
    {
      rl_gets();
    }
  return 0;
}

make main CXXFLAGS=-I/usr/include/xenomai LDFLAGS="-lnative -lpthread -
lncurses -lreadline -lxenomai"

./main
>
<now resize your xterm window>
Segmentation fault

Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

On Monday 10 January 2011 21:22:41 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > On Monday 10 January 2011 19:25:48 Gilles Chanteperdrix wrote:
> >> Peter Soetens wrote:
> >>> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> >>>> Peter Soetens wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> A while ago, I was advised to call xeno_sigshadow_install() after a
> >>>>> library installed a sigwinch signal handler (I believe this was
> >>>>> Xenomai 2.5.1). Could it be that this is no longer supported in
> >>>>> recent versions ? What is the correct way to avoid a segfault if an
> >>>>> application installed a sigwinch handler after Xenomai did ?
> >>>> 
> >>>> I think we already answered that at the time, but if you install your
> >>>> own sigwinch handler, you should:
> >>>> - register it with the SA_SIGINFO flag
> >>>> - call xeno_sigwinch_handler and consider that the signal is for the
> >>>> application only if this function returns 0.
> >>> 
> >>> This is indeed in the API docs, but it's not an option since it's a
> >>> third party library (readline) doing this, it doesn't depend on or
> >>> know Xenomai.
> >> 
> >> Actually, readline behaviour is highly configurable, and looking a bit
> >> at its documentation, we find that its behaviour with regard to sigwinch
> >> is configurable, see:
> >> rl_catch_sigwinch
> >> rl_resize_terminal
> > 
> > But we *want* to catch sigwinch/resize_terminal, since this happens quite
> > often. Without this signal the terminal width is not being communicated
> > to the readline library and it displays its columns in a too large or
> > too small width.
> > 
> > It's the terminal emulator giving us this signal, and it is meaningful to
> > us. It's Xenomai doing something fundamentally flawed, or I
> > fundamentally misunderstand it.
> 
> Look at the documentation of rl_catch_sigwinch, rl_resize_terminal, they
> have been made precisely, for your use-case. rl_catch_sigwinch will get
> readline not to catch the signal.
> 
> Then you will register a signal handler for your application, which
> calls, xeno_sigwinch_handler, and if that returns zero, calls
> rl_resize_terminal.
> 
> > Why can't you register a signal handler, without interfering
> > with other handlers for the same signal ?
> 
> Well, signal handlers are a per-process global ressource, look at
> sigaction documentation, this API is done this way, this is not
> Xenomai's fault, not even Linux' fault, you are barking at the wrong
> tree. That is precisely the reason why readline gives you access to
> rl_catch_sigwinch, rl_resize_terminal, and Xenomai to
> xeno_sigwinch_handler.

I see. I'll give it another shot.

Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Monday 10 January 2011 17:50:05 Gilles Chanteperdrix wrote:
>> Peter Soetens wrote:
>>> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
>>>> Peter Soetens wrote:
>>>>> Hi,
>>>>>
>>>>> A while ago, I was advised to call xeno_sigshadow_install() after a
>>>>> library installed a sigwinch signal handler (I believe this was Xenomai
>>>>> 2.5.1). Could it be that this is no longer supported in recent versions
>>>>> ? What is the correct way to avoid a segfault if an application
>>>>> installed a sigwinch handler after Xenomai did ?
>>>> I think we already answered that at the time, but if you install your
>>>> own sigwinch handler, you should:
>>>> - register it with the SA_SIGINFO flag
>>>> - call xeno_sigwinch_handler and consider that the signal is for the
>>>> application only if this function returns 0.
>>> This is indeed in the API docs, but it's not an option since it's a third
>>> party library (readline) doing this, it doesn't depend on or know
>>> Xenomai.
>>>
>>>> If you can not do that, then redefine SIGSHADOW in
>>>> include/asm-generic/syscall.h to a different value, and recompile both
>>>> Xenomai user-space and kernel-space support. Note however that when
>>>> starting applications in gdb you will then have to type:
>>>>
>>>> handle <the_new_signal> pass nostop print
>>>>
>>>> If you want to be able to debug Xenomai applications.
>>> Hmm....
>>>
>>> So defining the xeno_sigshadow_install() function ourselves (since it's
>>> not in any Xenomai header) and calling it after the readline signal
>>> handlers were installed is not gonna work ?
>> The thing is that xeno_sigshadow_installi is an internal function,
>> particularily, it is not thread safe. The exported function is
>> xeno_sigshadow_install_once, but it will not do anything the second time
>> it gets called.
>>
>> If you take care of this thread-safety issue, calling
>> xeno_sigshadow_install should be OK, since it just installs
>> xeno_sigshadow_handler as a handler for SIGSHADOW, calling
>> xeno_sigwinch_handler, then the handler your application registered
>> before. All this code is relatively simple, and you will find it in
>> src/skins/common/sigshadow.c
>>
>> Now, I suspect the issue you have is something else, so, could you post
>> the faulting code, reduced to a simple self-contained test case?
> 
> main.cpp:
> #include <readline/readline.h>
> #include <readline/history.h>
> #include <xenomai/native/task.h>
> #include <malloc.h>
> #include <sys/mman.h>
> #include <stdio.h>
> 
> char* line_read = 0;
> 
> char *rl_gets ()
> {
>   /* If the buffer has already been allocated,                                                                                                                                                                 
>      return the memory to the free pool. */
>   if (line_read)
>     {
>       free (line_read);
>       line_read = 0;
>     }
> 
>   if (rl_set_signals() != 0)
>     printf("Error setting signals !\n");
> 
>   line_read = readline ( ">" );
> 
>   /* If the line has any text in it,                                                                                                                                                                           
>      save it on the history. */
>   if (line_read && *line_read) {
>     add_history (line_read);
>   }
>   return (line_read);
> }
> 
> int main(void)
> {
>   mlockall(MCL_CURRENT | MCL_FUTURE);
> 
>   RT_TASK xenotask;
>   rt_task_shadow( &(xenotask),0, 10, 0);
>   rl_completion_append_character = '\0'; // avoid adding spaces                                                                                                                                                
> 
>   if ( read_history(".history") != 0 ) {
>     read_history("~/.history");
>   }
> 
>   // Let readline intercept relevant signals                                                                                                                                                                   
>   if(rl_catch_signals == 0)
>     printf("Error catching signals !\n");
> 
>   if (rl_set_signals() != 0)
>     printf("Error setting signals !\n");
> 
>   while (1)
>     {
>       rl_gets();
>     }
>   return 0;
> }
> 
> make main CXXFLAGS=-I/usr/include/xenomai LDFLAGS="-lnative -lpthread -
> lncurses -lreadline -lxenomai"
> 
> ./main
> <now resize your xterm window>
> Segmentation fault

You can not do that, Xenomai requires that xeno_sigwinch_handler be
called when SIGWINCH is received. To do that, you have either:
- to arrange for Xenomai xeno_sigshadow_install_once to be called after
the time when readline installs its handlers, that is what calling
xeno_sigshadow_install achieved, but this was fragile
- use another signal than SIGWINCH as internal signal used by Xenomai,
at the expense of some additional line launching gdb.
- define your own signal and handle correctly both Xenomai and
libreadline signals in that handler.


-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
> On Monday 10 January 2011 17:50:05 Gilles Chanteperdrix wrote:
>> Peter Soetens wrote:
>>> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
>>>> Peter Soetens wrote:
>>>>> Hi,
>>>>>
>>>>> A while ago, I was advised to call xeno_sigshadow_install() after a
>>>>> library installed a sigwinch signal handler (I believe this was Xenomai
>>>>> 2.5.1). Could it be that this is no longer supported in recent versions
>>>>> ? What is the correct way to avoid a segfault if an application
>>>>> installed a sigwinch handler after Xenomai did ?
>>>> I think we already answered that at the time, but if you install your
>>>> own sigwinch handler, you should:
>>>> - register it with the SA_SIGINFO flag
>>>> - call xeno_sigwinch_handler and consider that the signal is for the
>>>> application only if this function returns 0.
>>> This is indeed in the API docs, but it's not an option since it's a third
>>> party library (readline) doing this, it doesn't depend on or know
>>> Xenomai.
>>>
>>>> If you can not do that, then redefine SIGSHADOW in
>>>> include/asm-generic/syscall.h to a different value, and recompile both
>>>> Xenomai user-space and kernel-space support. Note however that when
>>>> starting applications in gdb you will then have to type:
>>>>
>>>> handle <the_new_signal> pass nostop print
>>>>
>>>> If you want to be able to debug Xenomai applications.
>>> Hmm....
>>>
>>> So defining the xeno_sigshadow_install() function ourselves (since it's
>>> not in any Xenomai header) and calling it after the readline signal
>>> handlers were installed is not gonna work ?
>> The thing is that xeno_sigshadow_installi is an internal function,
>> particularily, it is not thread safe. The exported function is
>> xeno_sigshadow_install_once, but it will not do anything the second time
>> it gets called.
>>
>> If you take care of this thread-safety issue, calling
>> xeno_sigshadow_install should be OK, since it just installs
>> xeno_sigshadow_handler as a handler for SIGSHADOW, calling
>> xeno_sigwinch_handler, then the handler your application registered
>> before. All this code is relatively simple, and you will find it in
>> src/skins/common/sigshadow.c
>>
>> Now, I suspect the issue you have is something else, so, could you post
>> the faulting code, reduced to a simple self-contained test case?
> 
> main.cpp:
> #include <readline/readline.h>
> #include <readline/history.h>
> #include <xenomai/native/task.h>
> #include <malloc.h>
> #include <sys/mman.h>
> #include <stdio.h>
> 
> char* line_read = 0;
> 
> char *rl_gets ()
> {
>   /* If the buffer has already been allocated,                                                                                                                                                                 
>      return the memory to the free pool. */
>   if (line_read)
>     {
>       free (line_read);
>       line_read = 0;
>     }
> 
>   if (rl_set_signals() != 0)
>     printf("Error setting signals !\n");

By the way, here you are installing the libreadline signals again. So,
if you managed to install Xenomai signal handler with
xeno_sigshadow_install, here you are overriding it again.

-- 
                                                                Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Peter Soetens]

On Monday 10 January 2011 21:45:24 Gilles Chanteperdrix wrote:
> Peter Soetens wrote:
> > On Monday 10 January 2011 17:50:05 Gilles Chanteperdrix wrote:
> >> Peter Soetens wrote:
> >>> On Monday 10 January 2011 17:24:28 Gilles Chanteperdrix wrote:
> >>>> Peter Soetens wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> A while ago, I was advised to call xeno_sigshadow_install() after a
> >>>>> library installed a sigwinch signal handler (I believe this was
> >>>>> Xenomai 2.5.1). Could it be that this is no longer supported in
> >>>>> recent versions ? What is the correct way to avoid a segfault if an
> >>>>> application installed a sigwinch handler after Xenomai did ?
> >>>> 
> >>>> I think we already answered that at the time, but if you install your
> >>>> own sigwinch handler, you should:
> >>>> - register it with the SA_SIGINFO flag
> >>>> - call xeno_sigwinch_handler and consider that the signal is for the
> >>>> application only if this function returns 0.
> >>> 
> >>> This is indeed in the API docs, but it's not an option since it's a
> >>> third party library (readline) doing this, it doesn't depend on or
> >>> know Xenomai.
> >>> 
> >>>> If you can not do that, then redefine SIGSHADOW in
> >>>> include/asm-generic/syscall.h to a different value, and recompile both
> >>>> Xenomai user-space and kernel-space support. Note however that when
> >>>> starting applications in gdb you will then have to type:
> >>>> 
> >>>> handle <the_new_signal> pass nostop print
> >>>> 
> >>>> If you want to be able to debug Xenomai applications.
> >>> 
> >>> Hmm....
> >>> 
> >>> So defining the xeno_sigshadow_install() function ourselves (since it's
> >>> not in any Xenomai header) and calling it after the readline signal
> >>> handlers were installed is not gonna work ?
> >> 
> >> The thing is that xeno_sigshadow_installi is an internal function,
> >> particularily, it is not thread safe. The exported function is
> >> xeno_sigshadow_install_once, but it will not do anything the second time
> >> it gets called.
> >> 
> >> If you take care of this thread-safety issue, calling
> >> xeno_sigshadow_install should be OK, since it just installs
> >> xeno_sigshadow_handler as a handler for SIGSHADOW, calling
> >> xeno_sigwinch_handler, then the handler your application registered
> >> before. All this code is relatively simple, and you will find it in
> >> src/skins/common/sigshadow.c
> >> 
> >> Now, I suspect the issue you have is something else, so, could you post
> >> the faulting code, reduced to a simple self-contained test case?
> > 
> > main.cpp:
> > #include <readline/readline.h>
> > #include <readline/history.h>
> > #include <xenomai/native/task.h>
> > #include <malloc.h>
> > #include <sys/mman.h>
> > #include <stdio.h>
> > 
> > char* line_read = 0;
> > 
> > char *rl_gets ()
> > {
> > 
> >   /* If the buffer has already been allocated,
> >   
> >      return the memory to the free pool. */
> >   
> >   if (line_read)
> >   
> >     {
> >     
> >       free (line_read);
> >       line_read = 0;
> >     
> >     }
> >   
> >   if (rl_set_signals() != 0)
> >   
> >     printf("Error setting signals !\n");
> >   
> >   line_read = readline ( ">" );
> >   
> >   /* If the line has any text in it,
> >   
> >      save it on the history. */
> >   
> >   if (line_read && *line_read) {
> >   
> >     add_history (line_read);
> >   
> >   }
> >   return (line_read);
> > 
> > }
> > 
> > int main(void)
> > {
> > 
> >   mlockall(MCL_CURRENT | MCL_FUTURE);
> >   
> >   RT_TASK xenotask;
> >   rt_task_shadow( &(xenotask),0, 10, 0);
> >   rl_completion_append_character = '\0'; // avoid adding spaces
> >   
> >   if ( read_history(".history") != 0 ) {
> >   
> >     read_history("~/.history");
> >   
> >   }
> >   
> >   // Let readline intercept relevant signals
> >   if(rl_catch_signals == 0)
> >   
> >     printf("Error catching signals !\n");
> >   
> >   if (rl_set_signals() != 0)
> >   
> >     printf("Error setting signals !\n");
> >   
> >   while (1)
> >   
> >     {
> >     
> >       rl_gets();
> >     
> >     }
> >   
> >   return 0;
> > 
> > }
> > 
> > make main CXXFLAGS=-I/usr/include/xenomai LDFLAGS="-lnative -lpthread -
> > lncurses -lreadline -lxenomai"
> > 
> > ./main
> > <now resize your xterm window>
> > Segmentation fault
> 
> You can not do that, Xenomai requires that xeno_sigwinch_handler be
> called when SIGWINCH is received. To do that, you have either:
> - to arrange for Xenomai xeno_sigshadow_install_once to be called after
> the time when readline installs its handlers, that is what calling
> xeno_sigshadow_install achieved, but this was fragile
> - use another signal than SIGWINCH as internal signal used by Xenomai,
> at the expense of some additional line launching gdb.
> - define your own signal and handle correctly both Xenomai and
> libreadline signals in that handler.

So what I did to get it to work is this:

declare in my own files (a C++ program):
extern "C"
int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt);

-> this function is nowhere declared in a header

Then write:
void rl_sigwinch_handler(int sig, siginfo_t *si, void *ctxt) {
        if (xeno_sigwinch_handler(sig, si, ctxt) == 0)
            rl_resize_terminal();
}

And when initializing readline:

        rl_catch_sigwinch = 0;
        struct sigaction sa;
        sa.sa_sigaction = &rl_sigwinch_handler;
        sa.sa_flags = SA_SIGINFO;
        sigaction(SIGWINCH, &sa, 0);

which works. I have guarded the xenomai-specific code with #if 
CONFIG_XENO_VERSION_MAJOR == 2 && CONFIG_XENO_VERSION_MINOR >= 5
stanzas. I'm not sure at which exact version this function was introduced.

Thanks for oiling my rusty signal handling skills.

Peter

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
>> - define your own signal and handle correctly both Xenomai and
>> libreadline signals in that handler.
> 
> So what I did to get it to work is this:
> 
> declare in my own files (a C++ program):
> extern "C"
> int xeno_sigwinch_handler(int sig, siginfo_t *si, void *ctxt);
> 
> -> this function is nowhere declared in a header

We can probably arrange that, we would have to put this declaration in a
header included in all the skin headers.

> Then write:
> void rl_sigwinch_handler(int sig, siginfo_t *si, void *ctxt) {
>         if (xeno_sigwinch_handler(sig, si, ctxt) == 0)
>             rl_resize_terminal();
> }
> 
> And when initializing readline:
> 
>         rl_catch_sigwinch = 0;
>         struct sigaction sa;
>         sa.sa_sigaction = &rl_sigwinch_handler;
>         sa.sa_flags = SA_SIGINFO;
>         sigaction(SIGWINCH, &sa, 0);
> 
> which works. I have guarded the xenomai-specific code with #if 
> CONFIG_XENO_VERSION_MAJOR == 2 && CONFIG_XENO_VERSION_MINOR >= 5
> stanzas. I'm not sure at which exact version this function was introduced.

This was introduced in 2.5.0. So, this is correct. In 2.4, each skin had
its own signal handler, and they ended up being chained if you used
several skins.

-- 
					    Gilles.

Re: [Xenomai-help] Correct use of xeno_sigshadow_install()

[Gilles Chanteperdrix]

Peter Soetens wrote:
>         struct sigaction sa;
>         sa.sa_sigaction = &rl_sigwinch_handler;
>         sa.sa_flags = SA_SIGINFO;

You probably want sa.sa_fags = SA_SIGINFO | SA_RESTART here.

And you should initialize sa.sa_mask.

-- 
					    Gilles.