Bug 905013 – NSPR pthread_key_t leak and memory corruption

Bug 905013 - NSPR pthread_key_t leak and memory corruption

Summary:	NSPR pthread_key_t leak and memory corruption

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	nspr (Show other bugs)
Sub Component:
Version:	6.4
Hardware:	All Linux

Priority	high Severity high
Target Milestone:	alpha
Target Release:	---
Assigned To:	Elio Maldonado Batiz
QA Contact:	Hubert Kario
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:	633519
Blocks:	835616 817178
	Show dependency tree / graph

Reported:	2013-01-28 06:50 EST by Aleš Mareček
Modified:	2014-06-11 11:28 EDT (History)
CC List:	15 users (show)

See Also:
Fixed In Version:	nspr-4.9.5-2.el6
Doc Type:	Bug Fix
Doc Text:	Cause: The NSPR posix threads library did not delete keys it had allocated and failed to perform proper checks at cleanup time. Consequence: If the NSPR shared libraries got repeatedly loaded and unloaded during the lifetime of a single process, NSPR might repeatedly allocate the same key again and again, with never freeing it up. Eventually the memory available for thread specific keys will be exhausted and the application will fail. Fix: NSPR keeps track of whether a key should be deleted. At finalization time it checks whether it has has been successfully intialized, cleanup has been done already, and whether a key has been created and must be deleted. Result: Processes no longer experience memory exhaustion or corruption when they have to repeatedly load and unload the NSPR shared libraries.
Story Points:	---
Clone Of:	633519
Environment:
Last Closed:	2013-11-21 01:10:41 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Patch made from what I picked up from the upstream bug (1.69 KB, patch) 2013-08-09 00:36 EDT, Elio Maldonado Batiz	no flags	Details \| Diff
The original bug reproducer attached to Bug 633519 (1.06 KB, text/x-csrc) 2013-08-14 12:50 EDT, Elio Maldonado Batiz	no flags	Details
Log file produced by executing the test (565.32 KB, text/x-log) 2013-08-14 12:53 EDT, Elio Maldonado Batiz	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Mozilla Foundation	749849	None	None	None	Never

Groups: None (edit)

Comment 3 Elio Maldonado Batiz 2013-08-09 00:36:50 EDT

Created attachment 784716 [details]
Patch made from what I picked up from the upstream bug

Comment 4 Kai Engert (:kaie) 2013-08-12 16:47:26 EDT

I refreshed my memory by rereading... the upstream bug.

The good news is:
  Upstream has applied a basic fix, and that fix has been contained
  in NSPR since version 4.9.3 

I believe that RHEL 6.4 has already been updated to NSPR 4.9.5, and therefore the basic fix should already be available.

I'd like to ask that you please repeat the testing of the server issue, to check that it has been sufficiently fixed.


However, more details: Bob had identified another scenario where we might still leak. There has been disagreements and stalling upstream which would be the correct approach to fix the remaining issue.

The patch that Elio has attached in comment 3 was my proposal to fix the remaining issue at upstream. That patch already god some reviewing from Bob, but not yet a final review.

In other words, here's my recommandation:


(A) Please test if existing NSPR 4.9.5 is sufficient to fix the issue.

    If it is, we should mark this bug a resolved and wait for upstream
    to complete and pick up remaining fixes later.

(B) If your testing with NSPR 4.9.5 shows we still have this bug,
    we will provide a scratch RPM with the suggested remaining fix.

Comment 5 Elio Maldonado Batiz 2013-08-14 12:50:36 EDT

Created attachment 786613 [details]
The original bug reproducer attached to Bug 633519

Comment 6 Elio Maldonado Batiz 2013-08-14 12:53:33 EDT

Created attachment 786615 [details]
Log file produced by executing the test

Produce by follwing the instructions at the top of the source file:

$ make tsdleak CFLAGS="-Wall -O2 -I/usr/include/nspr4" LDFLAGS="-ldl -lpthread"
cc -Wall -O2 -I/usr/include/nspr4  -ldl -lpthread  tsdleak.c   -o tsdleak
$ MALLOC_CHECK_=2 ./tsdleak 1> tsdleak.log 2>&1
$ grep fail tsdleak.log

Neither of printf's with 'dlopen failed:' or 'dlsym failed: were hit.

Comment 12 errata-xmlrpc 2013-11-21 01:10:41 EST

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1558.html

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