Bug 73452 - %gs segment register reset when calling pthread signal handler on SMP
Summary: %gs segment register reset when calling pthread signal handler on SMP
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-04 20:52 UTC by Need Real Name
Modified: 2007-04-18 16:46 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-16 10:58:00 UTC
Embargoed:


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

Description Need Real Name 2002-09-04 20:52:56 UTC
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 20:56:53 UTC
Created attachment 74913 [details]
test program

Comment 2 Arjan van de Ven 2002-09-04 21:01:17 UTC
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 21:14:00 UTC
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 10:56:21 UTC
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 10:58:00 UTC
this is solved by NPTL for sure in RHL9.

Comment 6 Alan Hourihane 2003-06-16 12:31:07 UTC
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.