From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1792 invoked by alias); 29 Oct 2003 10:17:23 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 1777 invoked from network); 29 Oct 2003 10:17:21 -0000 Received: from unknown (HELO hotmail.com) (64.4.47.45) by sources.redhat.com with SMTP; 29 Oct 2003 10:17:21 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 02:17:21 -0800 Received: from 220.244.224.42 by by9fd.bay9.hotmail.msn.com with HTTP; Wed, 29 Oct 2003 10:17:20 GMT X-Originating-IP: [220.244.224.42] X-Originating-Email: [arashp@hotmail.com] From: "Arash Partow" To: cygwin@cygwin.com Cc: tpfaff@gmx.net Bcc: Subject: Re: pthread problem with latest cygwin dll snapshot Date: Wed, 29 Oct 2003 12:39:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2003 10:17:21.0014 (UTC) FILETIME=[D6AC3160:01C39E05] X-SW-Source: 2003-10/txt/msg01722.txt.bz2 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/