Bug 109432 - Race in pthreads signal handling
Race in pthreads signal handling
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-11-07 15:04 EST by Aidan Van Dyk
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-13 14:25:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aidan Van Dyk 2003-11-07 15:04:25 EST
Description of problem:

There is a race of signal handling when a program is linked against
libpthreads (linuxthreads) on redhat linux <= 8.

In linuxthreads/signals.c: __sigaction(...)
    if (__libc_sigaction(sig, newactp, oact) == -1)
       return -1;
    if (act)
        __sighandler[sig].old = (arch_sighandler_t) act->sa_handler;

In linuxthreads/sighandler.c: __pthread_sighandler(...)
    CALL_SIGHANDLER(__sighandler[signo].old, signo, ctx);

The problem is when SIG_DFL|SIG_IGN|SIG_ERR is the current handler,
and a new one is being installed.  If the signal comes in after
__pthread_sighandler has been installed, but before
__sighandler[sig].old has been set, then __sighandler[sig].old == -1,
0, or 1, causing segfault when __pthread_sighandler() tries to invoke
it as a function.

A fix would be to make __pthread_sighandler() check it before
following it, or make __sigaction block/unblock the signal around the
race points.

Version-Release number of selected component:
Comment 1 Ulrich Drepper 2003-11-07 18:50:27 EST
Signals and LinuxThreads don't mix.  There will always we problems. 
Even if this specific problem is worked around this doesn't meant he
code will work 100%.

If you want to use signals, use NPTL.  *Nothing* else is supported.
Comment 2 Aidan Van Dyk 2003-11-10 09:08:09 EST
We are not using threads.  But we use unixODBC, which links against
pthreads to get its mutex for locking.  Just having pthreads linked in
cause it to take strong symbol for sigaction.

So our single-threaded IO dispatching process segfaults regularly on
all redhat versions with glibc-2.2.

Are there NTPL updates available for RH 8 and 7?

Should we be providing our own unixODBC which gives both -lodbc and

Comment 3 Ulrich Drepper 2003-11-10 16:50:56 EST
There will never be official NPTL support for RHL8 or earlier.  If
somebody wants to try it, they are welcome.

Try the test release for the upcoming RHL8 errata at


and let us know whether it works or not.
Comment 4 Ulrich Drepper 2003-11-20 12:54:55 EST
Ping.  Did you try the errata code?  If I don't get any reply I'll
assume the problem is fixed.
Comment 5 Aidan Van Dyk 2003-11-20 12:58:55 EST
Sorry - I had missed your comments.

Comment 6 Ulrich Drepper 2003-11-20 13:04:21 EST
We wait for info...
Comment 7 Aidan Van Dyk 2003-11-20 13:44:30 EST
Seems to be working well in a test sandbox.

It has been hammered for 20 minutes (still ongoing).  Prevous max was
around 15 seconds...

Is this errata coming soon?  Any .src.rpms for them?
Comment 8 Aidan Van Dyk 2003-12-10 12:33:34 EST
Any chances we can get the same pthread_sighandler fix from the
glibc-2.3 based errata into the glibc-2.2 based errata for RH 7?

Something similar to glibc-lt-sigaction.patch?
Comment 9 Aidan Van Dyk 2004-01-13 14:04:25 EST
Comment 10 Ulrich Drepper 2004-01-13 14:25:29 EST
No RHL7.x version is supported anymore.  Create your own binaries if
you want.

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