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
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

- Raw text -