Bug 146710

Summary: pthread_getspecific gets non-NULL value for new key
Product: Red Hat Enterprise Linux 3 Reporter: Erik Kane <erikkane>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: msimons, roland
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-096 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-18 10:00:03 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
sample program with build & run instructions none

Description Erik Kane 2005-01-31 17:07:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Memory locations returned by pthread_getspecific are not zero'ed
across pthread_key_delete/pthread_key_create calls, as stated in the
documentation "The value initialized associated with the returned key
 is NULL".

The result is that a new key returned by thread_key_create /
pthread_getspecific will not be initialized to zero if:

     ((the area was freed by a pthread_key_delete) and
     (when freed the pthread_getspecific area was not NULL))

This problem happens on AS 3 when NPTL is not used
(LD_ASSUME_KERNEL=2.4.1).

The problem does not recreate on AS 3 when NPTL is used 
(LD_ASSUME_KERNEL=2.4.20 or not setting LAK).

The problem was does not appear to happen on AS 2.1 

Please see the Sample_Run (attached below) for more details.

Version-Release number of selected component (if applicable):
glibc-2.3.2-95.20.i686

How reproducible:
Always

Steps to Reproduce:
1. Extract attached files
2. Build program by running "make"
3. Run program using NPTL: "LD_ASSUME_KERNEL=2.4.20 ./getspecific" (works)
4. Run program without NPTL: "LD_ASSUME_KERNEL=2.4.1 ./getspecific"
(fails)
    

Actual Results:  see attached file "Sample_Run"

Additional info:
Comment 1 Erik Kane 2005-01-31 17:10:35 EST
Created attachment 110465 [details]
sample program with build & run instructions
Comment 3 Jakub Jelinek 2005-02-14 18:36:00 EST
For RHEL4 fixed in glibc-2.3.4-2.4.
Comment 4 Jakub Jelinek 2005-02-15 01:51:17 EST
For RHEL3 fixed in glibc-2.3.2-95.32.
Comment 5 Mike Simons 2005-02-22 12:18:56 EST
This patch fixes the test case and the real program it came from.

- When should the offical RHEL3 glibc-2.3.2-95.32 be available?
Comment 6 Mike Simons 2005-03-11 12:28:27 EST
hrmm... been a while and still no errata released, when should
an offical RHEL3 binary be available?
Comment 7 Mike Simons 2005-05-16 16:44:24 EDT
so, it's been a few months... and glibc-2.3.2-95.32 is still not available
as an errata for RHEL3, what's blocking this?
Comment 8 Tim Powers 2005-05-18 10:00:04 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-256.html