From steve@cfg2.navinet.net Tue Aug 24 21:13:20 1999
Return-Path: <steve@cfg2.navinet.net>
Received: from cfg2.navinet.net (cfg2.navinet.net [216.67.14.26])
	by hub.freebsd.org (Postfix) with ESMTP id 8D41014E50
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 24 Aug 1999 21:13:18 -0700 (PDT)
	(envelope-from steve@cfg2.navinet.net)
Received: (from steve@localhost)
	by cfg2.navinet.net (8.9.3/8.9.2) id AAA32479;
	Wed, 25 Aug 1999 00:20:48 -0400 (EDT)
	(envelope-from steve)
Message-Id: <199908250420.AAA32479@cfg2.navinet.net>
Date: Wed, 25 Aug 1999 00:20:48 -0400 (EDT)
From: steve@copacetic.net
Sender: steve@cfg2.navinet.net
Reply-To: steve@copacetic.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: Memory leak in -current pthreads select() implementation
X-Send-Pr-Version: 3.2

>Number:         13368
>Category:       misc
>Synopsis:       Memory leak in -current pthreads select() implementation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 24 21:20:01 PDT 1999
>Closed-Date:    Tue Aug 31 13:18:18 PDT 1999
>Last-Modified:  Tue Aug 31 13:19:17 PDT 1999
>Originator:     Steve Bernacki, Jr.
>Release:        FreeBSD 3.2-RELEASE i386
>Organization:
NaviNet, Inc.
>Environment:

	FreeBSD testbed.eng.navinet.net 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08
 GMT 1999     jkh@cathair:/usr/src/sys/compile/GENERIC  i386

>Description:

	FreeBSD's pthreads implements select() internally as poll().  In doing this,
	it dynamically allocates memory (one per thread) to store the pollfd struct.
	While subsequent calls to poll() in the same thread will reuse this memory,
	it is never free()ed when the thread is exited.
	

>How-To-Repeat:

	This problem can be seen in threaded applications that frequently spawn
	threads (one per transaction, for example) that call select().  Memory usage
	for this process will steadily increase over time.

>Fix:
	
	Applying the following patch to uthread_exit.c fixed the steady increase in
	memory:


*** uthread_exit.c.orig	Thu Aug  5 19:16:47 1999
--- uthread_exit.c	Tue Aug 24 23:42:51 1999
***************
*** 134,139 ****
--- 134,145 ----
  		_thread_cleanupspecific();
  	}
  
+ 	/* Free thread-specific poll_data structure, if allocated */
+ 	if (_thread_run->poll_data.fds != NULL) {
+ 		free(_thread_run->poll_data.fds);
+ 		_thread_run->poll_data.fds = NULL;
+ 	}
+ 
  	/*
  	 * Defer signals to protect the scheduling queues from access
  	 * by the signal handler:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: dt 
State-Changed-When: Tue Aug 31 13:18:18 PDT 1999 
State-Changed-Why:  
Suggested patch committed, thanks. 
>Unformatted:
