Bug 73452 - %gs segment register reset when calling pthread signal handler on SMP
%gs segment register reset when calling pthread signal handler on SMP
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-04 16:52 EDT by Need Real Name
Modified: 2007-04-18 12:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-16 06:58:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program (5.11 KB, text/plain)
2002-09-04 16:56 EDT, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2002-09-04 16:52:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Description of problem:
I've been working on a program to get process stat from the /proc. The program
uses pthreads (linuxthreads) and on 2.4 SMP kernels it always SIGSEGV. It works
fine on 2.4 UP kernels and 2.2 UP and SMP kernels.

Investigating the problem I've found that the SIGSEGV always happens on the
signal handler of the linuxthreads (pthread_handle_sigrestart). And it happens
because the %gs segment register is 0.

I've made this little program to test. It will SIGSEGV after 30 min-1 hour on a
SMP box. I've tested with this Red Hat box:
Linux 2.4.9-21enterprise #1 SMP Thu Jan 17 13:37:56 EST 2002 i686 unknown
glibc-2.2.4-29

Sometimes you'll see that only the main thread will stay alive and the other
ones will die.

The work around is to use the /lib/libpthread.so.0 (this one doesn't uses the
%gs register) instead of the default /lib/i686/libpthread.so.0. At least on a
Red Hat box it works fine.

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


How reproducible:
Always

Steps to Reproduce:
1.Run the program
2.
3.
	

Actual Results:  SIGSEGV

Additional info:
Comment 1 Need Real Name 2002-09-04 16:56:53 EDT
Created attachment 74913 [details]
test program
Comment 2 Arjan van de Ven 2002-09-04 17:01:17 EDT
please try the current 7.2 kernel (2.4.9-34) since some threading bits got
fixed; also the 2.4.18-10 7.3 kernel is a useful point since that'll be used for
future 7.2 errata.
Comment 3 Need Real Name 2002-09-04 17:14:00 EDT
Unfortunately I can't upgrade this machine because it's a prodution one and I
don't have a SMP machine to test it.

Besides I'm already using the workaround. I just filed the bug so others can
know this. I've expended a lot of time (2 months) trying to find what was going
on...
Comment 4 Alan Hourihane 2003-06-16 06:56:21 EDT
I also suffered this problem, and was using a stock 2.4.19 kernel compiled from 
source.
Comment 5 Arjan van de Ven 2003-06-16 06:58:00 EDT
this is solved by NPTL for sure in RHL9.
Comment 6 Alan Hourihane 2003-06-16 08:31:07 EDT
Sure, but not everyone can upgrade to such a new release just yet.

But I understand that you would need some payment to fix this type of problem 
on an older release.

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