From: Eric Piel <Eric.Piel@Bull.Net>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Bug: Blocking of RT signals in a pause()
Date: Fri, 21 Feb 2003 16:38:24 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590709805904@msgid-missing> (raw)
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
Hello,
I'm still very newby to kernel hacking, however while trying to port the
hrtimer-posix patch (which is now in the main tree) to ia64 I think I
came to find a bug.
Basically the problem is that while my program is in a pause() I can not
receive any signal > 32 (RT signals) even if I've just unblocked them.
In addition if I unblock signal 32 then all the RT signals are
unblocked. This strange behaviour is not reproductible during a sleep().
No idea came to my mind to test other system calls so I can't say more.
Attached to this email, there is a small program to highlight this
behaviour. The bug was reproductible under 2.4ia64 and 2.5ia64 but never
with an ia32 arch. To run it on your computer you compile it:
cc -Wall -DPAUSE -g bug_signal_rt.c -o bug_signal_rt
*and then run it as a background process (so you can send it some
signals):
>./bug_signal_rt &
[3] 15424
Testing SIGNAL1=33 with signal 32 unblocked.
*you send it a signal 33:
>kill -33 15424
The signal 33 was received.
Testing SIGNAL1=33 with signal 33 unblocked.
*send the signal 33:
>kill -33 15424
###nothing happens
So you can see the bug when it received the signal 33 while unblocking
only the signal 32!
If it's not so clear you can have a look at usage_bug_signal_rt.txt to
read a bit more.
Whatever, I tried to correct the bug but after reading
arch/ia64/kernel/signal.c I could find anything to help. My knowledge of
the kernel is still quite poor. So if someone could confirm the bug and
also give me some hints about where I should hunt this bug I would be
very grateful...
Cheers
Eric
[-- Attachment #2: bug_signal_rt.c --]
[-- Type: text/plain, Size: 1228 bytes --]
/* to enable the signal 33 you have to unblock signal 32 instead of 33!*/
#include <sys/types.h>
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#define SIGNAL1 33 /* SIGRTMIN */
int sig_received;
void sigminrt_handler(int signo, siginfo_t * info, void * ptr)
{
sig_received = 1; /* we passed the handler */
}
int do_test(int sig)
{
sig_received = 0;
#ifdef PAUSE
pause(); /* wait a lot */
#else
sleep(10); /* wait a little bit */
#endif
if (sig_received) printf("The signal %d was received.\n", sig);
else printf("The signal %d was NOT received.\n", sig);
return (sig_received);
}
int main()
{
struct sigaction sigact;
sigset_t new_mask;
sigact.sa_sigaction =sigminrt_handler;
sigact.sa_flags = SA_SIGINFO;
sigemptyset(&sigact.sa_mask);
sigaction(SIGNAL1, &sigact, NULL);
sigfillset(&new_mask);
sigdelset(&new_mask, 32);
sigprocmask(SIG_SETMASK, &new_mask, NULL);
printf("Testing SIGNAL1=%d with signal %d unblocked.\n", SIGNAL1, 32);
do_test(SIGNAL1);
sigfillset(&new_mask);
sigdelset(&new_mask, SIGNAL1);
sigprocmask(SIG_SETMASK, &new_mask, NULL);
printf("Testing SIGNAL1=%d with signal %d unblocked.\n", SIGNAL1, SIGNAL1);
do_test(SIGNAL1);
return 0;
}
[-- Attachment #3: usage_bug_signal_rt.txt --]
[-- Type: text/plain, Size: 1085 bytes --]
How to compile and use bug_signal_rt
Compile it with:
cc -Wall -g bug_signal_rt.c -o bug_signal_rt
to provide a sleep() mechanism
or:
cc -Wall -DPAUSE -g bug_signal_rt.c -o bug_signal_rt
to provide a pause() mechanism
Usage:
*run the program in background and note the PID:
./bug_signal_rt &
[3] 15424
Testing SIGNAL1=33 with signal 32 unblocked.
*send it a signal 33:
kill -33 15424
The signal 33 was received.
Testing SIGNAL1=33 with signal 33 unblocked.
*redo it:
kill -33 15424
*if nothing happens you can kill it:
kill -KILL 15424
What it should demonstrate:
In pause() the RT signals blocking methods are not working as specified/expected.
All signals >= 32 are blocked if the flag for signal 32 is set. Flags > 32 are taken into account. This problem doesn't happens in a sleep().
The program blocks all blockable signals execpted one and set an signal handler for signal 33. Then it call a sleep() or a pause() and when going out checks if the signal handler was called.
It does this procedure twice, first with signal 32 unblocked, second with signal 33 unblocked.
reply other threads:[~2003-02-21 16:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-105590709805904@msgid-missing \
--to=eric.piel@bull.net \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.