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 14:00:03 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:
Attachments:
Description Flags
sample program with build & run instructions none

Description Erik Kane 2005-01-31 22:07:37 UTC
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 22:10:35 UTC
Created attachment 110465 [details]
sample program with build & run instructions

Comment 3 Jakub Jelinek 2005-02-14 23:36:00 UTC
For RHEL4 fixed in glibc-2.3.4-2.4.

Comment 4 Jakub Jelinek 2005-02-15 06:51:17 UTC
For RHEL3 fixed in glibc-2.3.2-95.32.

Comment 5 Mike Simons 2005-02-22 17:18:56 UTC
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 17:28:27 UTC
hrmm... been a while and still no errata released, when should
an offical RHEL3 binary be available?

Comment 7 Mike Simons 2005-05-16 20:44:24 UTC
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 14:00:04 UTC
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