Re: pthread problem with latest cygwin dll snapshot

[Thomas Pfaff <tpfaff@gmx.net>]

Hi Arash,

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)
8. make

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).

Good luck.

Thomas

Arash Partow wrote:
> 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 :)
> 


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