This is the mail archive of the
mailing list for the Cygwin project.
Re: pthread problem with latest cygwin dll snapshot
- From: "Arash Partow" <arashp at hotmail dot com>
- To: cygwin at cygwin dot com
- Cc: tpfaff at gmx dot net
- Date: Wed, 29 Oct 2003 10:17:20 +0000
- Subject: Re: pthread problem with latest cygwin dll snapshot
I'll try doing as you have suggested, I'll rebuild the dll and see how
things turn out from there.
One thing I forgot to mention in my previous e- mail, was that when you run
multiple instances of ThreadTest, when they start crashing, the Error
Windows that pop-up all have the same "referenced memory" location. I just
thought this is rather strange.
1 thing though, did you try piping the stdout to tee? I found that doing
that was a sure way of crashing it.
Anywayz thanx heaps for the help so-far I'll get back to you after I get
the building done.
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.
i downloaded TaskInfo, installed it on a 2,5 GHz P4 W2000 box, tried free
RAM (slow and fast) and your Test did not crash. I rebuilded the cygwin DLL
while your test was running, still no crash.
If you are interested to dig a little deeper download the snapshot source
and build your own dll.
The steps are:
1. Download cygwin-src-20031028.tar.bz2
2. Create a directory /usr/src/cygwin. Go to that directory.
3. Untar the source tarball (tar -xpjvf cygwin-src-20031028.tar.bz2)
4. Create a directory named BUILD.
5. Goto BUILD
6. set CFLAGS, CXXFLAGS and LDFLAGS to '-g' (export CFLAGS='-g'; export
CXXFLAGS='-g'; export LDFLAGS='-g')
7. configure (../cygwin-snapshot-20031028-1/configure --prefix=/usr)
There is no need for a make install, just copy new-cygwin1.dll from
i686-pc-cygwin/winsup/cygwin into your /cygwin/bin directory as cygwin1.dll
after you have terminated all cygwin programs.
If you see a crash in the cygwin dll you can use addr2line to get the
source line (addr2line -e /bin/cygwin1.dll "address", for example addr2line
-e /bin/cygwin1.dll 0x61061756).
If you want to debug the dll you might want to set the CFLAGS and CXXFLAGS
to '-O0 -g' before you configure. To set breakpoints in the cygwin DLL
start 'gdb TestThread', set a breakpoint at main and start your app. After
it stops at main you can set breakpoints at functions in the cygwin dll (b
pthread_create for example).
Arash Partow wrote:
Greetings to Thomas and all others involved in cygwin pthreads
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
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
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
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
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
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
the last call before the crash was to the cygwin1.dll. I've done my
with both debug on and off and different levels of optimization, in all
cases they produce the same outcome.
All you need to do is be doing something and it will crash the more
the processing of the other tasks the more quickly the ThreadTest will
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
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
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
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
I've tried running the ThreadTest in bash ( I know it wont change much)
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
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
I think the goal should be 5million threads being created, with other
also running in the background. If the ThreadTest can achive that level of
stability, I wont bug this list anymore :)
Hot chart ringtones and polyphonics. Go to
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html