Bug 146710 - pthread_getspecific gets non-NULL value for new key
Summary: pthread_getspecific gets non-NULL value for new key
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-31 22:07 UTC by Erik Kane
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHBA-2005-096
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-18 14:00:03 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:096 0 normal SHIPPED_LIVE glibc bug fix update 2005-06-09 04:00:00 UTC
Red Hat Product Errata RHSA-2005:256 0 high SHIPPED_LIVE Low: glibc security update 2005-05-18 04:00:00 UTC
Sourceware 739 0 None None None Never

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



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