This is the mail archive of the 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: cvs cygwin1.dll

On Sun, Sep 22, 2002 at 03:08:41PM +0000, Guy Harrison wrote:
>On Fri, 20 Sep 2002 11:56:57 -0400, Christopher Faylor <>
>>On Fri, Sep 20, 2002 at 11:26:42AM +0000, Guy Harrison wrote:
>>>On Wed, 18 Sep 2002 15:35:53 -0400, Christopher Faylor <>
>Shame us non-developers can't get it "readonly".

Yeah.  Life's a bitch, isn't it?

Anyway, you are looking at the wrong message.

Remember this?

On Fri, Sep 20, 2002 at 11:56:57AM -0400, Christopher Faylor wrote:
>I suspect that this is actualy due to a deadlock in the code
>which was recently discussed in cygwin-developers.

If you look at my message which immediately follows the one that you mention
which actually *mentions*, you will see the cause of at least one
deadlock-on-exit in cygwin.

Robert Collins has vowed to fix this problem this weekend.  Until then,
however, I have commented out the code in question.

>>I don't think it has anything to do with suspended threads.  You can
>>certainly verify this by adding code to kill the threads specifically,
>>though, and see what happens.
>I did. I declared threads[1]. All the work gets shoved onto
>cygthread::simplestub which neither suspends nor stays resident.

Not the same thing at all.

>Hung process:
>Relevent log:
>Quick Key:
><GetCurrentProcessId/GetCurrentThreadId> 90 GetCommandLine() chars
>[n/32] =threads[n] of NTHREADS=32
>mti    =main_thread_id
>nam    =ignore fixed on "mti" here
>sdc    =SD_count (member added to cygthread class) suspend count
>av     =threads[].avail
>id     =threads[].id
>h      =threads[].h
>sus    =another suspend count
>gle    =GetLastError() for failed "sus"
><344/509> cli(90):J:\cygwin\bin\sh.exe
>pid=344 tid=509[0/32]{mti:509}: nam=[main] sdc=-999 av=877 id=0 h=296
>sus=2 gle=0 
>pid=344 tid=509[1/32]{mti:509}: nam=[main] sdc=-999 av=212 id=0 h=300
>sus=2 gle=0 
>pid=344 tid=509[2/32]{mti:509}: nam=[main] sdc=-999 av=894 id=0 h=304
>sus=2 gle=0 
>pid=344 tid=509[3/32]{mti:509}: nam=[main] sdc=-999 av=482 id=0 h=308
>sus=2 gle=0 
>The ::SuspendThread() and ::ResumeThread() calls in assign
>their result directly to SD_count. I set it explicity to silly negative
>values at these points:
>-999 in cygthread::runner() after their ::CreateThread()
>-99 in cygthread::stub just prior to init_exceptions()
>-2 cygthread::exit_thread ::SetEvent()
>-9999 cygthread::stub ::ExitThread()
>Nothing else touches 'SD_count'. The above output is generated by a
>function 'SD_DumpLiving()' inserted immediately prior to ::ExitProcess()
>within _pinfo::exit().
>Our hung process is definately suspended.

Not necessarily.  I see nothing in the above which would disprove the
theory that this is the problem which I raised in cygwin-developers.  Of
course, I am not 100% sure that I understand the above data.  However,
I'm not going to devote too much time to studying it since there is an
obvious problem in the cygwin DLL now and you haven't, AFAICT, addressed
that.  This makes your analysis suspect until you generate a version of
the DLL without the already known problem.

However, if you want to provide an actual analysis of how the thread
could be in a suspended state with someone waiting for it, that would be
welcome.  So far, everything you've provided points to the fact that the
process in question is stuck in a deadlock state during ExitProcess, which
sort of confirms my theory.  That's why you can't debug it.


Unsubscribe info:
Bug reporting:

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