From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12649 invoked by alias); 29 Oct 2003 06:10:32 -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 12445 invoked from network); 29 Oct 2003 06:10:14 -0000 Received: from unknown (HELO hotmail.com) (64.4.47.21) by sources.redhat.com with SMTP; 29 Oct 2003 06:10:14 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 28 Oct 2003 22:10:13 -0800 Received: from 203.94.167.77 by by9fd.bay9.hotmail.msn.com with HTTP; Wed, 29 Oct 2003 06:10:12 GMT X-Originating-IP: [203.94.167.77] 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 09:36:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Oct 2003 06:10:13.0127 (UTC) FILETIME=[50903170:01C39DE3] X-SW-Source: 2003-10/txt/msg01716.txt.bz2 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 :) Regards Arash Partow PS: The updated version of ThreadTest can be downloaded from: http://www.partow.net/downloads/ThreadTest-Prototype.zip __________________________________________________ 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 > >this time I am not able to reproduce your problem. > >Before I continue debugging I suggest that you check the return codes of >some pthread API functions first and call the pthread_functions only with a >valid thread id. > >For example change > >void Thread::start() >{ > pthread_create(&threadID,NULL,&(Thread::threadFunction),this); > pthread_detach(threadID); >} > >to > >void Thread::start() >{ > int res; > res = pthread_create(&threadID,NULL,&(Thread::threadFunction),this); > if (res) > setThreadState(THREAD_DEAD); > else > pthread_detach(threadID); >} > >Please contact me if this still doesn't help. > >Thomas > > . _________________________________________________________________ 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/