This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: SIGCLD (?) problem
"Christopher Faylor" <cgf@redhat.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