From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30228 invoked by alias); 29 Oct 2003 09:36:27 -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 29696 invoked from network); 29 Oct 2003 09:35:58 -0000 Received: from unknown (HELO four-d.de) (129.247.190.4) by sources.redhat.com with SMTP; 29 Oct 2003 09:35:58 -0000 Received: (from mail@localhost) by four-d.de (8.9.3/8.9.3) id KAA05847; Wed, 29 Oct 2003 10:35:57 +0100 X-Authentication-Warning: atacama.four-d.de: mail set sender to using -f Received: from algeria.intern.net(192.168.2.71) by atacama.four-d.de via smap (V2.1+anti-relay+anti-spam) id xma005822; Wed, 29 Oct 03 10:35:51 +0100 Message-ID: <3F9F89F5.1060004@gmx.net> Date: Wed, 29 Oct 2003 12:10:00 -0000 From: Thomas Pfaff User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arash Partow CC: cygwin@cygwin.com Subject: Re: pthread problem with latest cygwin dll snapshot References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg01720.txt.bz2 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/