Bug 118044

Summary: Bug in NPTL regarding POSIX signal handling
Product: Red Hat Enterprise Linux 3 Reporter: Need Real Name <udas>
Component: kernelAssignee: Roland McGrath <roland>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 3.0CC: drepper, gnuss, jakub, mingo, roland, tburke
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-24 01:20:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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;

void
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;
}

int
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
http://www.opengroup.org/austin/

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
requirements:

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?

thanks 
-/sheryl

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
2.6.9,
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.