This is the mail archive of the cygwin@cygwin.com 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: pthread problem with latest cygwin dll snapshot


Hi Thomas,

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.



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





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














.

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


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