Bug 118044 - Bug in NPTL regarding POSIX signal handling
Summary: Bug in NPTL regarding POSIX signal handling
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Roland McGrath
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-11 13:43 UTC by Need Real Name
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2005-04-24 01:20:31 UTC

Attachments (Terms of Use)

Description Need Real Name 2004-03-11 13:43:59 UTC
Description of problem:
POSIX signal handling still not happening

Version-Release number of selected component (if applicable):

How reproducible:
Easily seen in a MT program

Steps to Reproduce:
1.Call setitimer in one thread
2.Exit the thread
3.Process never gets the ALRMs
Actual results:

Expected results:

Additional info:

Comment 1 Elliot Lee 2004-03-11 17:25:29 UTC
glibc, not tftp

Comment 2 Jakub Jelinek 2004-03-11 17:40:59 UTC
You mean like:
#include <signal.h>
#include <stdio.h>
#include <time.h>
#include <pthread.h>
#include <sys/time.h>

int ret;

sig (int signo)
  ret = 1;

void *
tf (void *arg)
  struct itimerval it;
  it.it_value.tv_sec = 1;
  it.it_value.tv_usec = 0;
  it.it_interval = it.it_value;
  if (setitimer (ITIMER_REAL, &it, NULL))
      puts ("setitimer failed");
      exit (1);
  return NULL;

main (void)
  signal (SIGALRM, sig);

  pthread_t th;
  if (pthread_create (&th, NULL, tf, NULL))
      puts ("pthread_create failed");
      exit (1);

  pause ();
  return 0;


Comment 3 Jakub Jelinek 2004-03-11 17:53:35 UTC
Can you please file an interpretation request with the Austin group?
The standard is certainly not very clear whether the 3 listed timers
must be per-process or per-thread and how should be the timer expiration
signalled in a mt environment.

Comment 4 Jakub Jelinek 2004-03-11 17:54:24 UTC

Comment 5 Roland McGrath 2004-03-11 21:24:00 UTC
The standard certainly manages not to be very clear about it, true.
I have always taken it as unambiguous that itimers are per-process,
not per-thread, and feel confident that is the intended specification.
This is already on my list of known-wrong things in the Linux kernel.

Comment 6 David Lawrence 2004-03-15 18:52:33 UTC
Changing product and version.

Comment 7 Roland McGrath 2004-03-20 01:58:07 UTC
On rechecking the standard, I think it is already unambiguous that the
timers are per-process.  I don't think we need any clarification from
the standards body.

I consider this a known bug in Linux 2.6, where it persists.
I do intend to get it fixed there at some point, but when that can
happen depends totally on upstream acceptance.  This is the kind of
behavior that we would be unlikely to make different in a future RHEL
kernel than whatever the future upstream kernel does.  However, even
if it does change in the future it seems doubtful that we would change
system call semantics in this way in an RHEL3 update kernel.  

Comment 8 Need Real Name 2004-07-12 06:30:58 UTC
As additional details to the problem as originally found, and our

We need system time independant, hires timers. Of course a call like
the Solaris gethrtime be used. But that is not there on Linux. Instead
we can also set up a high resolution kernel timer and get a signal
when it times out, aka, setitimer. Problem is, what if the thread
calling the setitimer exits / is cancelled before the timer goes off?
Due to this bug, the process to which the thread belonged to never
gets a signal delivered, since the timer itself (in Linux) is per
thread, and dies with the thread.

Comment 11 sheryl sage 2004-07-27 18:19:14 UTC
Can we have an update on when in 2.6 you are looking at fixing this?


Comment 12 Roland McGrath 2005-04-24 01:20:31 UTC
I'm closing this old bug for RHEL3, which is not going to get a semantics change
like this.  The upstream kernel has these changes as of 2.6.12rc2 and they
should be in the released 2.6.12 soon.  They are not in RHEL4, which is based on
and it is unlikely that a change in semantics such as this will come into RHEL4
in an update.  At any rate, this bug is for RHEL3 and RHEL3 certainly won't change.
RHEL5 will certainly have this fixed, and RHEL4 can be addressed in a separate
bug if there is a need for it to be changed there.

Note You need to log in before you can comment on or make changes to this bug.