Red Hat Bugzilla – Full Text Bug Listing
|Summary:||pthread_getspecific gets non-NULL value for new key|
|Product:||Red Hat Enterprise Linux 3||Reporter:||Erik Kane <erikkane>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED ERRATA||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||RHBA-2005-096||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-18 10:00:03 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 2 Jakub Jelinek 2005-02-07 05:50:39 EST
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