Bug 109432
| Summary: | Race in pthreads signal handling | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Aidan Van Dyk <aidan> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | drepper, fweimer |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-01-13 19:25:29 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: | |||
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. 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 -lobdc-nmt? 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 ftp://people.redhat.com/drepper/glibc-errata/rhl8 and let us know whether it works or not. Ping. Did you try the errata code? If I don't get any reply I'll assume the problem is fixed. Sorry - I had missed your comments. Testing... We wait for info... 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? 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? *PING* No RHL7.x version is supported anymore. Create your own binaries if you want. |
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: glibc-2.2.93