From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9519 invoked by alias); 24 Mar 2004 13:42:14 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 9507 invoked from network); 24 Mar 2004 13:42:11 -0000 Received: from unknown (HELO smtpauth2-ext.prodigy.net) (207.115.63.116) by sources.redhat.com with SMTP; 24 Mar 2004 13:42:11 -0000 Received: from hume.com (adsl-65-67-62-170.dsl.austtx.swbell.net [65.67.62.170]) (authenticated bits=0) by smtpauth2-ext.prodigy.net (8.12.10 auth mps/8.12.10) with ESMTP id i2ODfx4A662288; Wed, 24 Mar 2004 08:42:00 -0500 Message-ID: <406190AA.20706@hume.com> Date: Wed, 24 Mar 2004 13:42:00 -0000 From: Ed Hume User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) MIME-Version: 1.0 To: rpj@callisto.canberra.edu.au CC: pthreads-win32@sources.redhat.com Subject: Re: memory leak?? References: <759C12D9893C354785F7FFE43B4155000B34F1@omacex06.corp.westworlds.com> <405C09A8.10403@spth.de> <40613372.6000600@callisto.canberra.edu.au> In-Reply-To: <40613372.6000600@callisto.canberra.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00040.txt.bz2 You should not pay much attention to the Task Manager. The "Mem Usage" statistic includes freed memory that has yet to be harvested by the OS. The "VM Size" is a better statistic for analyzing leakage, but you should not try to meter single calls, there is too much other activity. Do the calls once to get initialization done, take a snapshot of VM Size, and then do the calls in a loop and do it some odd number of thousands of times such as 7000 and see if you change VM size by 7000 times some amount. Ross Johnson wrote: > There's nothing that big in the library and no arrays of objects that > big etc that I recall. What exactly is included in the size that Task > Manager reports? Could it be pages of the DLL itself that have been > loaded into memory? The DLL is only 52k and half of it could easily > have been loaded after the first pthread_create() call. > > What happens if you put the getchar() ... getchar() block in a loop - > do you get 28k added each time? > > Ross > > Philipp Klaus Krause wrote: > >> Arnett, Don L. schrieb: >> >>> I'm new to using pthreadsWin32. According to the TaskMgr display >>> this program is using about 28K more memory at the second getchar() >>> than it was at the first getchar(). I found a couple of discussions >>> of memory leaks in the list archives and it usually was a programmer >>> problem, but I don't see what I'm missing. Thanks for any input. >>> >>> #include >>> #include >>> #include >>> >>> void *pvDoSomething(void *poThreadArgs); >>> >>> int main(int argc, char* argv[]) { >>> >>> pthread_t *poThread; >>> >>> getchar(); >>> >>> poThread = (pthread_t*)calloc(1,sizeof(pthread_t)); >>> pthread_create(poThread,NULL,pvDoSomething,NULL); >>> pthread_detach(*poThread); >>> free(poThread); >>> >>> getchar(); >>> >>> return 0; >>> } >>> >>> void *pvDoSomething(void *poThreadArgs) { >>> return NULL; >>> } >>> >>> >> The created thread does not necessarily run and exit immidiately. >> It might still exist when you reach the second getchar(). > > > > -- Regards, Ed Hume Hume Integration Software http://www.hume.com/