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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]