[Xenomai-help] Core Dump on possibly buggy signal handler installation

[Xenomai-help] Core Dump on possibly buggy signal handler installation

[Eric Noulard]

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

Hi all,

I've recently discovered a "possible" bug
only occuring with a system running xenomai-patched kernel.

I have set up a machine (dual-core intel machine).
The machine is installed with a Fedora Core 6 and
may be booted (test purpose)  with different kernel:

1) linux 2.6.20-0119.rt8
    which is an Ingo Molnar precompiled preempt-rt patched kernel
    you may find it there:
     http://people.redhat.com/mingo/realtime-preempt/

2) 2.6.20-xeno-2.3.1-ipipe-1.7-03
    which is a xenomai enabled kernel I've configured and compiled.

My test application is a mixed C/C++ USER-land application
which currently make no xenomai specific call.

The application core dumps at the end of its execution
with the xenomai enabled kernel whereas it does not
with the preempt-rt kernel.

I track down the problem to a misuse of sigaction calls
which install SIGALARM handler with sa_flags not properly setup.

My code is definitely buggy but I let you know because in the first
place it was puzzling to have different (but consistent and repeatable) behavior
on different kernel, with core dump using the Xenomai-enabled kernel :((.

You may try it  yourself:

gcc -o BadTimerSigHandler TimerSigHandler.c

generates a the buggy binary, while

gcc -DGOOD_SIGHANDLING -o GoodTimerSigHandler TimerSigHandler.c

generates the good one.

I don't really know if it may indicates a xenomai bug or not
but I would be glad to understand WHY is this.

I mean I know that uninitialized memory have unpredictable consequence
but here the bug is persistent after rerun, reboot, power cycle etc...


-- 
Erk

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

#include <stdio.h>
#include <sys/types.h>
#include <signal.h>

static int stop = 0;

void
SignalHandler(int Signal) {
  int pid = getpid();
  printf("Received signal %d. Stopping peacefully.\n", Signal);
  stop = 1;
}


int
main() {

  int i;
  struct sigaction a ;

  signal(SIGINT , SignalHandler);
  signal(SIGPIPE, SignalHandler);
  
  a.sa_handler = SignalHandler ;
  sigemptyset(&a.sa_mask);
#if defined(GOOD_SIGHANDLING)
  a.sa_flags    = SA_RESTART;
#endif
  sigaction(SIGALRM, &a, NULL);

  alarm(3);
    
  for (i=0;i<2000 && !stop ;++i) {

    printf(".");
    fflush(stdout);
    sleep(1);
  }
}

Re: [Xenomai-help] Core Dump on possibly buggy signal handler installation

[Gilles Chanteperdrix]

Eric Noulard wrote:
> Hi all,
> 
> I've recently discovered a "possible" bug
> only occuring with a system running xenomai-patched kernel.
> 
> I have set up a machine (dual-core intel machine).
> The machine is installed with a Fedora Core 6 and
> may be booted (test purpose)  with different kernel:
> 
> 1) linux 2.6.20-0119.rt8
>     which is an Ingo Molnar precompiled preempt-rt patched kernel
>     you may find it there:
>      http://people.redhat.com/mingo/realtime-preempt/
> 
> 2) 2.6.20-xeno-2.3.1-ipipe-1.7-03
>     which is a xenomai enabled kernel I've configured and compiled.
> 
> My test application is a mixed C/C++ USER-land application
> which currently make no xenomai specific call.
> 
> The application core dumps at the end of its execution
> with the xenomai enabled kernel whereas it does not
> with the preempt-rt kernel.
> 
> I track down the problem to a misuse of sigaction calls
> which install SIGALARM handler with sa_flags not properly setup.
> 
> My code is definitely buggy but I let you know because in the first
> place it was puzzling to have different (but consistent and repeatable) behavior
> on different kernel, with core dump using the Xenomai-enabled kernel :((.
> 
> You may try it  yourself:
> 
> gcc -o BadTimerSigHandler TimerSigHandler.c
> 
> generates a the buggy binary, while
> 
> gcc -DGOOD_SIGHANDLING -o GoodTimerSigHandler TimerSigHandler.c
> 
> generates the good one.
> 
> I don't really know if it may indicates a xenomai bug or not
> but I would be glad to understand WHY is this.
> 
> I mean I know that uninitialized memory have unpredictable consequence
> but here the bug is persistent after rerun, reboot, power cycle etc...
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> #include <stdio.h>
> #include <sys/types.h>
> #include <signal.h>
> 
> static int stop = 0;
> 
> void
> SignalHandler(int Signal) {
>   int pid = getpid();
>   printf("Received signal %d. Stopping peacefully.\n", Signal);
>   stop = 1;
> }
> 
> 
> int
> main() {
> 
>   int i;
>   struct sigaction a ;
> 
>   signal(SIGINT , SignalHandler);
>   signal(SIGPIPE, SignalHandler);
>   
>   a.sa_handler = SignalHandler ;
>   sigemptyset(&a.sa_mask);
> #if defined(GOOD_SIGHANDLING)
>   a.sa_flags    = SA_RESTART;
> #endif

You should initialize sa_flags with the bugous value on your platform,
different platforms, different compilers may lead to a different value
of sa_flags here, possibly preventing us from seeing the bug.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Core Dump on possibly buggy signal handler installation

[Jan Kiszka]

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

Eric Noulard wrote:
> Hi all,
> 
> I've recently discovered a "possible" bug
> only occuring with a system running xenomai-patched kernel.
> 
> I have set up a machine (dual-core intel machine).
> The machine is installed with a Fedora Core 6 and
> may be booted (test purpose)  with different kernel:
> 
> 1) linux 2.6.20-0119.rt8
>    which is an Ingo Molnar precompiled preempt-rt patched kernel
>    you may find it there:
>     http://people.redhat.com/mingo/realtime-preempt/
> 
> 2) 2.6.20-xeno-2.3.1-ipipe-1.7-03
>    which is a xenomai enabled kernel I've configured and compiled.
> 
> My test application is a mixed C/C++ USER-land application
> which currently make no xenomai specific call.
> 
> The application core dumps at the end of its execution
> with the xenomai enabled kernel whereas it does not
> with the preempt-rt kernel.
> 
> I track down the problem to a misuse of sigaction calls
> which install SIGALARM handler with sa_flags not properly setup.
> 
> My code is definitely buggy but I let you know because in the first
> place it was puzzling to have different (but consistent and repeatable)
> behavior
> on different kernel, with core dump using the Xenomai-enabled kernel :((.
> 
> You may try it  yourself:
> 
> gcc -o BadTimerSigHandler TimerSigHandler.c
> 
> generates a the buggy binary, while
> 
> gcc -DGOOD_SIGHANDLING -o GoodTimerSigHandler TimerSigHandler.c
> 
> generates the good one.
> 
> I don't really know if it may indicates a xenomai bug or not
> but I would be glad to understand WHY is this.
> 
> I mean I know that uninitialized memory have unpredictable consequence
> but here the bug is persistent after rerun, reboot, power cycle etc...
> 

What is a.sa_flags initialised when it is not initialised? 0? Maybe you
can nail it down to defined state that causes the core dump reliably.
Then we can also track down what happens to your sigaction call and
if/why Xenomai/I-pipe changes the picture in some regard.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Core Dump on possibly buggy signal handler installation

[Eric Noulard]

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

2007/4/27, Jan Kiszka <jan.kiszka@domain.hid>:
> >
> > I mean I know that uninitialized memory have unpredictable consequence
> > but here the bug is persistent after rerun, reboot, power cycle etc...
> >
>
> What is a.sa_flags initialised when it is not initialised? 0? Maybe you
> can nail it down to defined state that causes the core dump reliably.
> Then we can also track down what happens to your sigaction call and
> if/why Xenomai/I-pipe changes the picture in some regard.

I did rerun as you suggest, find the code attached which
consistentely core dump with xenomai kernel and (seems to) do nothing
special with the other kernel.

a.sa_flags = 0xbff81578;


-- 
Erk

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

#include <stdio.h>
#include <sys/types.h>
#include <signal.h>

static int stop = 0;

void
SignalHandler(int Signal) {
  int pid = getpid();
  printf("Received signal %d. Stopping peacefully.\n", Signal);
  stop = 1;
}


int
main() {

  int i;
  struct sigaction a ;

  signal(SIGINT , SignalHandler);
  signal(SIGPIPE, SignalHandler);
  
  a.sa_handler = SignalHandler ;
  sigemptyset(&a.sa_mask);
#if defined(GOOD_SIGHANDLING)
  a.sa_flags    = SA_RESTART;
#else
  a.sa_flags    = 0xbff81578;
#endif
  sigaction(SIGALRM, &a, NULL);

  alarm(3);
    
  for (i=0;i<2000 && !stop ;++i) {

    printf(".");
    fflush(stdout);
    sleep(1);
  }
}

Re: [Xenomai-help] Core Dump on possibly buggy signal handler installation

[Paul]

Hi Eric

On Friday 27 April 2007 17:32, Eric Noulard wrote:
> 2007/4/27, Jan Kiszka <jan.kiszka@domain.hid>:
> > > I mean I know that uninitialized memory have unpredictable consequence
> > > but here the bug is persistent after rerun, reboot, power cycle etc...
> >
> > What is a.sa_flags initialised when it is not initialised? 0? Maybe you
> > can nail it down to defined state that causes the core dump reliably.
> > Then we can also track down what happens to your sigaction call and
> > if/why Xenomai/I-pipe changes the picture in some regard.
>
> I did rerun as you suggest, find the code attached which
> consistentely core dump with xenomai kernel and (seems to) do nothing
> special with the other kernel.
>
> a.sa_flags = 0xbff81578;

Try:

    a.sa_flags = 0x04000000;


Regards, Paul.

Re: [Xenomai-help] Core Dump on possibly buggy signal handler installation

[Jan Kiszka]

Paul wrote:
> Hi Eric
> 
> On Friday 27 April 2007 17:32, Eric Noulard wrote:
>> 2007/4/27, Jan Kiszka <jan.kiszka@domain.hid>:
>>>> I mean I know that uninitialized memory have unpredictable consequence
>>>> but here the bug is persistent after rerun, reboot, power cycle etc...
>>> What is a.sa_flags initialised when it is not initialised? 0? Maybe you
>>> can nail it down to defined state that causes the core dump reliably.
>>> Then we can also track down what happens to your sigaction call and
>>> if/why Xenomai/I-pipe changes the picture in some regard.
>> I did rerun as you suggest, find the code attached which
>> consistentely core dump with xenomai kernel and (seems to) do nothing
>> special with the other kernel.
>>
>> a.sa_flags = 0xbff81578;
> 
> Try:
> 
>     a.sa_flags = 0x04000000;
> 

Yep, red herring regarding Xenomai. I get the same sigsegv over plain
linux here, and looking at that bit above (SA_RESTORER), it also makes
sense: this declares sigaction::sa_restorer valid, an internal field
that you don't touch/initialise as well.

Jan