Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <004101c24194$734d82a0$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
References: <016a01c24148$e61594e0$6132bc3e AT BABEL> <20020811192301 DOT GA9017 AT redhat DOT com>
Subject: Re: SIGCLD (?) problem
Date: Mon, 12 Aug 2002 01:08:55 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

"Christopher Faylor" <cgf AT redhat DOT com> wrote:
> I don't see how there could be a race.  thread 2 should be the
> signal thread.  It would be interesting to see what it is doing.
> It sounds like it has not been started or something, which would
> make the "wait_for_me" function block forever.

(gdb) thread 2
[Switching to thread 2 (thread 1852.0x97c)]#0  0x77e8b650 in
_system_dlls__ ()
(gdb) where
#0  0x77e8b650 in _system_dlls__ ()
Cannot access memory at address 0x3


I get exactly the same result for threads 4 thru 9 as well; so
this does seem to be the hung-at-creation state (?) for a thread.

Thread 10 gives me:

(gdb) thread 10
[Switching to thread 10 (thread 1852.0x900)]#0  0x77f91771 in
_system_dlls__ ()
(gdb) where
#0  0x77f91771 in _system_dlls__ ()
#1  0x77e8b2d8 in _system_dlls__ ()

So, thread 1 is blocked in wait4; thread 3 in wait_subproc; thread
10 in wherever that is; while threads 2 and 4-9 are all at
0x77e8b650.

BTW I don't know how (i.e. I haven't bothered to find out how) to
convert these system DLL addresses into function names, so I hope
this is of some use.

> I've made some changes and added some assertions throughout the
code.
> I don't think they will solve the problem but it may make things
a
> little clearer if there is a problem.

Once I've updated everything, I'll try the re-build once or twice
more and see if I can catch it again.

> Could you check on the value of wait_sig_inited?  Is it
non-zero?
> The problem is that the process processing thread should not
have
> to be waiting for this.

(gdb) print wait_sig_inited
$4 = 0x14c

Give a shout if you want any more information: I'll keep the
process here for a while longer.

Cheers,

// Conrad