Subject: Re: pthread problem with latest cygwin dll snapshot
From: "Arash Partow" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 29 Oct 2003 06:10:12 +0000

Greetings to Thomas and all others involved in cygwin pthreads
implementation,

I made the changes that you advised, however the ThreadTest still crashes,
I also put some text to standard out when the result of pthread_create is
not equal to 0, the text does not show which leads to believe me the
problem does not occur there.

I also made modification to the garbage collector not to add the dead
thread to the thread list, rather just delete it immediately and also to
bark an error to the standard out which never gets displayed, hence further
proving that the problem is somewhere else.

There is no deterministic way to make it crash, just that it will
eventually crash in a very short period of time, if some other things are
done on the system. I wonder if you have tried downloading the shareware
version of the TaskInfo program I use, during its trial period everything
is enabled so you will be able to do the Free RAM (fast/slow) and also
maybe you can do something like play an mpeg in the background, and maybe
use the winsock by doing something on the net. One very unusual yet
interesting thing I noticed whilst running the ThreadTest, was that a split
second before it crashes, TaskInfo reports a huge amount of memory being
acquired by ThreadTest, by huge I mean around 100mb+ the amount is never
the same, but I've never seen it go below 100Mb, I'm sure there is
something wrong happening for something like that to be occur. the only
problem is I can't figure out whether the memory is being requested by the
cygwin layer on behalf of ThreadTest or by the cygwin layer for its own
purpose. I can be sure that no where in the ThreadTest do I acquire 100MB+
of memory from the OS.

Another thing i've noticed about the test crashing, is that even though its
a console app, windows barks an error, via an error window with the title
"ThreadTest.exe - Application Error", in the body of the window it says:
The instruction at "some mem address" refrenced memory at "some mem 
address".
The memory could not be "read".

But the strange thing is that even after this error window appears the
ThreadTest seems to run for some time still, you can see threads being
created, but after a certain amount of time that too stops. When you try to
close the error window down, another pops up under it, I think there is an
error window for each thread that stuffed up. But as before, GDB still says
the last call before the crash was to the cygwin1.dll. I've done my testing
with both debug on and off and different levels of optimization, in all the
cases they produce the same outcome.

All you need to do is be doing something and it will crash the more intense
the processing of the other tasks the more quickly the ThreadTest will
crash.

I've tried some other combinations for running the ThreadTest, in one
instance I ran 30 instances of the test and saw that "sometimes" when 1 of
them crashed other instances would also crash, this lead me to believe that
only 1 instance of cygwin dll is ever loaded into memory and that apps
using it look for one in the memory first before deciding whether or not
they should be loading the cygwin1.dll, One theory I came up with was that
the other instances that were crashing were in someway sequentially related
to the first instance that crashed meaning that either the instance that
crashed and instances that were executed prior to it crashed, or that the
instance and instances executed after it crashed, this theory turned out to
be false, when I copied the ThreadTest app 30 times each time appending a
number to its file name, then executing them sequentially based on their
number, I found that the apps died in a random fashion, no pattern could be
found.

I've tried running the ThreadTest in bash ( I know it wont change much) but
it crashes in there too, one deterministic way of making it crash is if
you pipe the stdout of ThreadTest to tee, ie:
ThreadTest | tee out.dat

This I can guarantee will crash within the 1st 1000000 threads being 
created.

Other than that I have no other ideas of ways to make it crash more
regurarly. I hope this will be enough information for you to continue your
debugging.

I think the goal should be 5million threads being created, with other tasks
also running in the background. If the ThreadTest can achive that level of
stability, I wont bug this list anymore :)

Regards

Arash Partow

PS: The updated version of ThreadTest can be downloaded from:
    http://www.partow.net/downloads/ThreadTest-Prototype.zip

__________________________________________________
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

>
>this time I am not able to reproduce your problem.
>
>Before I continue debugging I suggest that you check the return codes of 
>some pthread API functions first and call the pthread_functions only with a 
>valid thread id.
>
>For example change
>
>void Thread::start()
>{
>     pthread_create(&threadID,NULL,&(Thread::threadFunction),this);
>     pthread_detach(threadID);
>}
>
>to
>
>void Thread::start()
>{
>    int res;
>    res = pthread_create(&threadID,NULL,&(Thread::threadFunction),this);
>    if (res)
>      setThreadState(THREAD_DEAD);
>    else
>      pthread_detach(threadID);
>}
>
>Please contact me if this still doesn't help.
>
>Thomas
>
>

.

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

--
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/