This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: Bug report with source code attached
- To: 'Dave Baggett' <dmb at itasoftware dot com>, pthreads-win32 at sourceware dot cygnus dot com
- Subject: RE: Bug report with source code attached
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Date: Thu, 2 Mar 2000 10:45:52 -0500
Sorry, I didn't actually see a thread main line routine in your
code. However, it does seem to be an out of resource type error,
such as stack, memory, thread id's, etc. I personally haven't
seen the actually released code base... I submitted the code
that had been used for the bulk of the implementation. I am
not personally active it the maintaining of the library...
I simply provide advice, etc. if it's called for.
So, one thing to check is to walk through when you return from
your thread routine to determine that the library does, indeed,
release ALL thread resources when the thread terminates (this
is what is supposed to happen when a detached thread terminates)
Secondly, since your threads are SO short, they could actually
run to completion BEFORE you actually call pthread_detach.
You might consider calling pthread_detach from within the actual
thread to avoid this situation. Some investigation is required
to determine what will happen on calling pthread_detach on
a thread that has actually terminated. I would surmise that since
the thread had finished, there is no chance for the library to
actually clean up it's resources; hence you are leaking all the
thread's resources (memory, and actual thread ids). Please try
moving the pthread_detach to inside your thread as in
pthread_detach( pthread_self() );
Third, the library shouldn't be "crashing" when an out of resource
error occurs. Run the program from within the debugger and put a
break point in main. Use the Performance Monitor (Start... Programs...
Administrative Tools...) Select "Process" and find your process name.
Next add appropriate counters such as Private Bytes, etc. to monitor
your resource consumption.
I hope this helps,
From: Dave Baggett [mailto:email@example.com]
Sent: Wednesday, March 01, 2000 12:50 PM
Subject: Re: Bug report with source code attached
John Bossom wrote:
> 1) you didn't include the thread code, so we really don't
> know if all the threads are still consuming resources
> (and running!) or not. If they are you are chewing up
> all the system resources... there should be sufficient
> checks in both your code (and pthreads-win32) to deal
> with out of memory/resource errors (i.e. checking for
> failures of malloc, etc.)
I think I may have been confusing.
That wasn't a *piece* of the code that causes the crash --
that code *itself* will cause a crash. In other words, there
is no more code to show you as far as eliciting the bug
is concerned. Of course, in my real app the threads actually
do things, but that seems to have no bearing on this crash bug.
I watered down my test case to the code I sent, and that's all
you need to cause a crash. In other words, just paste that code
into "test.cpp", compile it, and run it. Within about 15
minutes the program should crash.
I know it looks pretty unlikely, but that's what happens
on my machine (NT SP5, 1GB RAM). I'd certainly be
interested to learn that nobody else can duplicate this crash
if that's the case -- that means I need to reinstall NT,