Bug 146710 - pthread_getspecific gets non-NULL value for new key
pthread_getspecific gets non-NULL value for new key
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-01-31 17:07 EST by Erik Kane
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2005-096
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 10:00:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sample program with build & run instructions (1.72 KB, application/octet-stream)
2005-01-31 17:10 EST, Erik Kane
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 739 None None None Never
Red Hat Product Errata RHBA-2005:096 normal SHIPPED_LIVE glibc bug fix update 2005-06-09 00:00:00 EDT
Red Hat Product Errata RHSA-2005:256 high SHIPPED_LIVE Low: glibc security update 2005-05-18 00:00:00 EDT

  None (edit)
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

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):

How reproducible:

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"

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.


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