This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with pthreads (serious memory leaks)


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]