Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: X-Originating-Email: [arashp AT hotmail DOT com] X-Sender: arashp AT hotmail DOT com In-Reply-To: <20050606030439.GA9161@trixie.casa.cgf.cx> From: "Arash Partow" To: cygwin AT cygwin DOT com Subject: Re: Problem with pthreads (serious memory leaks) Date: Mon, 06 Jun 2005 03:36:27 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-IsSubscribed: yes Hi Chris, > >You may be right, but I don't remember ever having to wade through 308K >worth of code to try to figure out a problem. Searching the archives, >I see that you had a program called "ThreadTest" which exposed a stdio >memory leak. I still have that program sitting around and it doesn't >seem at all similiar to "example1". > The example1 code itself is not but the support coding, the pthreads wrapper is the same code. > >OK in simple terms this is what I see: I run example1 and open up my > >taskmanager and taskinfo and slowly watch the amount of memory example1 > >is using increase continuously. > >And example1 is doing what? What functions is it calling? > Ok its a simple producer-consumer example. there are 2 classes my_producer and my_consumer. both classes are threaded (derived from a base thread class) my_producer continually creates strings via its produce method and places these strings on the link device (aka message queue), which is done via the underlying infrastructure code. my_consumer which has a reference to this other end of this link device is woken up when say there is "stuff" on the link. it goes off and lock the link to other users, gets all the "stuff" off the link then does whatever it does... its as simple as that. >When did you notice this behavior? Is it only in 1.5.17? > ok to be honest I'm not sure when it broke, because I'm not on windows a lot, but I'm VERY sure that the last time I saw it working properly was during February. As mentioned before I tried the test with as many snapshots as I could find, and they all seem to be causing a leak. > >I then focus on taskinfo (because it gives a more detailed > >view), and examine the the different aspects of the application > >running (the threads, the loaded modules etc...). Now I know > >just as well as anyone else that because say a program crashes > >in a standard lib routine, doesn't mean the routine is buggy. > >"crashes in a standard lib routine"? I don't see any mention of a >crash in your previous email. A crash is sometimes easier to debug >than a leak. What standard lib routine is this crashing in? > oh no you must of misunderstood me, I was only digressing, you see a few weeks ago on some threading news groups someone made a post saying that some code they had written was crashing within a particular libc routine. Someone else made the astute observation that it was most likely the data that was being passed into the routine that was corrupting the routine and not the routine itself. I found that to be rather interesting for some reason or another and hence felt i should share it with someone else. :) One final note, I've noticed that if in the my_producer class in the produce method, if the string lengths are set to 100 (instead of 1024), the memory leak magically disappears, I'm thinking this has something to do with the thread's stack_size, in any case I hope that helps. Kind regards Arash Partow __________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/