* RE: sig_send: wait for sig_complete event failed
@ 2000-09-20 3:27 Mortimer, Andy
2000-09-30 10:17 ` Chris Faylor
0 siblings, 1 reply; 16+ messages in thread
From: Mortimer, Andy @ 2000-09-20 3:27 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
Hi,
Chris Faylor writes:
> On Tue, Sep 19, 2000 at 06:10:35PM +0100, Mortimer, Andy wrote:
> >Hi Chris/list,
> >
> >Chris Faylor writes:
> >>On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
> >>>1184486202 [sig] bash 28849 sig_send: wait for sig_complete
> >>> event failed, sig 11, rc 258, Win32 error 0
> >> [...]
> >As noted in another message, the latest snapshots didn't work for me,
> >but I've applied just the patch referred to here and it has indeed
> >stopped the hang. Thanks, Chris! Now, I'm just left with the problem
> >of bash segfaulting inside Cygwin's signal handling thread ... ;-)
>
> Are you saying that you took the changes from the snapshot,
> applied them
> to 1.1.4 sources, and rebuilt a DLL?
Yes.
> Unfortunately, I can't decipher a snapshot if you're using a
> home grown
> DLL unless you're willing to tell me what all of the 6100* addresses
> resolve to symbolically.
I know. :-(
> For that you can use 'addr2line' or gdb.
I'd tried to use gdb to get this information, but I really
couldn't persuade it to play with me; I hadn't come
across addr2line before. (I even went to the lengths
of getting ld to produce a map file, but I didn't get
very far with that either :-/ ) The addresses in the
previous dump I sent resolve with addr2line to:
6100922E stack_info::init(unsigned long) exceptions.cc:226
6100922E stack_info::init(unsigned long) exceptions.cc:226
6100A2A3 interrupt_on_return(unsigned long, int, sigaction &, void *) exceptions.cc:663
6100A806 call_handler(int, sigaction &, void *) exceptions.cc:778
6100AF00 sig_handle(int) exceptions.cc:972
6103EE0E wait_sig(void *) sigproc.cc:1269
6100331A thread_stub(void *) debug.cc:91
77F04EE8 ?? ??:0
I wasn't sure which DLL to look in for the last entry. With
the changes I made to exceptions.cc, the lines referenced
above are:
226 sf.AddrPC.Offset = ((DWORD *) ebp)[1];
663 for (i = 0; i < 32 && thestack++ ; i++)
778 else if (!interrupt_on_return (ebp, sig, siga, handler))
972 rc = call_handler (sig, thissig, handler);
which shouldn't be out by more than a couple of lines from 1.1.4.
> Btw, the argv[0] problem should be fixed in the next snapshot.
Cool, perhaps I'll try that one out if I get a chance. Thanks!
(I'll also try the replacement DLL you sent by private mail if
I get a chance, but things are still running here, and it may
be a while before I have an opportunity with nothing
happening so I can unload the previous DLL! ;-)
Thanks for your help,
Andy
--
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com
[An automatic footer will be attached to this message. By posting to a
public mailing list, I implicitly give permission to read/disclose/copy
/delete/reply to/whatever the message.]
***********************************************************************
This transmission contains information which may be confidential and
which may also be privileged. It is intended for the named addressee
only. Unless you are the named addressee, or authorised to receive it
on behalf of the addressee you may not copy or use it, or disclose it
to anyone else. If you have received this transmission in error please
contact the sender. Thank you for your cooperation.
***********************************************************************
For more information about AEA Technology please visit our website at http://www.aeat.co.uk
AEA Technology plc registered office 329 Harwell, Didcot, Oxfordshire OX11 0QJ.
Registered in England and Wales, number 3095862.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send: wait for sig_complete event failed
2000-09-20 3:27 sig_send: wait for sig_complete event failed Mortimer, Andy
@ 2000-09-30 10:17 ` Chris Faylor
0 siblings, 0 replies; 16+ messages in thread
From: Chris Faylor @ 2000-09-30 10:17 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
On Wed, Sep 20, 2000 at 11:23:55AM +0100, Mortimer, Andy wrote:
>Chris Faylor writes:
>> On Tue, Sep 19, 2000 at 06:10:35PM +0100, Mortimer, Andy wrote:
>> >Hi Chris/list,
>> >
>> >Chris Faylor writes:
>> >>On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
>> >>>1184486202 [sig] bash 28849 sig_send: wait for sig_complete
>> >>> event failed, sig 11, rc 258, Win32 error 0
>> >> [...]
>> >As noted in another message, the latest snapshots didn't work for me,
>> >but I've applied just the patch referred to here and it has indeed
>> >stopped the hang. Thanks, Chris! Now, I'm just left with the problem
>> >of bash segfaulting inside Cygwin's signal handling thread ... ;-)
>>
>> Are you saying that you took the changes from the snapshot,
>> applied them
>> to 1.1.4 sources, and rebuilt a DLL?
>
>Yes.
>
>> Unfortunately, I can't decipher a snapshot if you're using a
>> home grown
>> DLL unless you're willing to tell me what all of the 6100* addresses
>> resolve to symbolically.
>
>I know. :-(
>
>> For that you can use 'addr2line' or gdb.
>
>I'd tried to use gdb to get this information, but I really
>couldn't persuade it to play with me; I hadn't come
>across addr2line before. (I even went to the lengths
>of getting ld to produce a map file, but I didn't get
>very far with that either :-/ ) The addresses in the
>previous dump I sent resolve with addr2line to:
>
>6100922E stack_info::init(unsigned long) exceptions.cc:226
>6100922E stack_info::init(unsigned long) exceptions.cc:226
>6100A2A3 interrupt_on_return(unsigned long, int, sigaction &, void *) exceptions.cc:663
>6100A806 call_handler(int, sigaction &, void *) exceptions.cc:778
>6100AF00 sig_handle(int) exceptions.cc:972
>6103EE0E wait_sig(void *) sigproc.cc:1269
>6100331A thread_stub(void *) debug.cc:91
>77F04EE8 ?? ??:0
>
>I wasn't sure which DLL to look in for the last entry. With
>the changes I made to exceptions.cc, the lines referenced
>above are:
I've added some more code to the snapshots in an attempt to work
around this problem. I don't know if I was successful or not. It's
hard to fix a problem when you can't duplicate it.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* sig_send: wait for sig_complete event failed
@ 2001-12-31 1:15 paul
0 siblings, 0 replies; 16+ messages in thread
From: paul @ 2001-12-31 1:15 UTC (permalink / raw)
To: cygwin
dear list,
anyone know what causes this error:
0 [win] darkbot 3467757 sig_send: wait for sig_complete event failed, signal
14, rc 258, Win32 error 0
i haven't found many people with signal 14 error (alarm signal?), i did some
tests, and whats really weird
is i only seem to get this error ONCE (the first time the application is
installed and run) after i kill it, and
run it again - no problem? (windows 2000 pro), but on winME it gives this
error everytime?
any clues?
thanks,
paul
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: sig_send: wait for sig_complete event failed
@ 2000-10-05 2:51 Mortimer, Andy
0 siblings, 0 replies; 16+ messages in thread
From: Mortimer, Andy @ 2000-10-05 2:51 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
Hi,
Chris Faylor writes:
> >> On Tue, Sep 19, 2000 at 06:10:35PM +0100, Mortimer, Andy wrote:
> >> >Chris Faylor writes:
> >> >>On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
> >> >>>1184486202 [sig] bash 28849 sig_send: wait for sig_complete
> >> >>> event failed, sig 11, rc 258, Win32 error 0
> >> >> [...]
> >> > Now, I'm just left with the problem
> >> >of bash segfaulting inside Cygwin's signal handling thread ... ;-)
[...]
> I've added some more code to the snapshots in an attempt to work
> around this problem. I don't know if I was successful or not.
Using the 2000-Sep-29 snapshot seems to have changed
something! It does seem to be more reliable (it's always
hard to tell with these things, but it only seems to have
dumped once in this way since I installed the snapshot).
I'll include the stackdump, but (partly because I've
changed from using bash to ash -- which doesn't
exhibit this problem -- for some of the more important
things) this now seems stable enough for me to use very
successfully. Thanks!
I don't know if you want to take this any further or not; I
don't really know what the problem is that you're trying to
fix now, so I don't really know that I can do much more to
help! I will certainly keep trying out any new snapshots if
this would help, or let me know if there's anything else I
can do, but short of coming up with a reproducible testcase
(which seems hard! )-: I'm stuck.
On which topic, what's the best forum for reporting bugs
in the snapshots? The 2000-Sep-29 snapshot appears to
be unable to resolve through symlinks to directories with
trailing slashes, and although I suspect it's been found
and fixed and is therefore not worth reporting, I can't
access the CVS sources though our firewall to check, and
there doesn't appear to be a later snapshot at the moment.
$ ln -s /bin dummy
$ ls dummy
[works]
$ ls dummy/
ls: dummy/: Not a directory
$ ls dummy/.
ls: dummy/.: Not a directory
$ ls dummy/cygwin1.dll
dummy/cygwin1.dll
Thanks,
Andy
--
Andy Mortimer, CFX Software Development
andy.mortimer@aeat.com
Exception: STATUS_ACCESS_VIOLATION at eip=6100BA85
eax=610986C8 ebx=00000000 ecx=00000000 edx=00000001 esi=00000014 edi=61098740
ebp=048BFA08 esp=048BFCA8 program=C:\cygwin\bin\bash.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame Function Args
048BFA08 6100BA85 (00000000, 00000000, 00000000, 00000000)
048BFCAC 6100BA85 (610986C8, 00000001, 77F88000, 77F60000)
048BFCDC 6100CB13 (00000001, 00000014, 048BFEFC, 0041BB04)
048BFDEC 6100D087 (00000014, 048BFEFC, 0041BB04, 00000000)
048BFF0C 6100D7DC (00000014, 00000014, 00000000, 000001F4)
048BFF6C 61041F46 (00000000, 048BFFB8, 61004128, 048BFFB0)
048BFFB8 6100414A (61092564, 00000000, 00000000, 61092564)
1570844 [sig] bash 315 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
1604484 [sig] bash 315 handle_exceptions: Error while dumping state (probably corrupted stack)
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send: wait for sig_complete event failed
2000-10-02 4:50 Mortimer, Andy
@ 2000-10-02 8:47 ` Chris Faylor
0 siblings, 0 replies; 16+ messages in thread
From: Chris Faylor @ 2000-10-02 8:47 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
On Mon, Oct 02, 2000 at 05:49:35AM -0600, Mortimer, Andy wrote:
>I will try to test the new snapshot sooner rather than later; I had
>a look just now, but the latest snapshot (2000-Sep-29) doesn't
>seem to include anything "obvious". Is this the one I should try,
>or will the changes be in the next snapshot build?
I'm usually pretty careful to only mention a snapshot when the code
is actually in the snapshot. The most recent snapshot has the code
that I was referring to.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: sig_send: wait for sig_complete event failed
@ 2000-10-02 4:50 Mortimer, Andy
2000-10-02 8:47 ` Chris Faylor
0 siblings, 1 reply; 16+ messages in thread
From: Mortimer, Andy @ 2000-10-02 4:50 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
Chris Faylor writes:
> On Wed, Sep 20, 2000 at 11:23:55AM +0100, Mortimer, Andy wrote:
> >> >>On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
> >> >>>1184486202 [sig] bash 28849 sig_send: wait for sig_complete
> >> >>> event failed, sig 11, rc 258, Win32 error 0
> >> >> [...]
> >> >As noted in another message, the latest snapshots didn't work for me,
> >> >but I've applied just the patch referred to here and it has indeed
> >> >stopped the hang. Thanks, Chris! Now, I'm just left with the problem
> >> >of bash segfaulting inside Cygwin's signal handling thread ... ;-)
> >
> >6100922E stack_info::init(unsigned long) exceptions.cc:226
> >6100922E stack_info::init(unsigned long) exceptions.cc:226
> >6100A2A3 interrupt_on_return(unsigned long, int, sigaction &, void *) exceptions.cc:663
> >6100A806 call_handler(int, sigaction &, void *) exceptions.cc:778
> >6100AF00 sig_handle(int) exceptions.cc:972
> >6103EE0E wait_sig(void *) sigproc.cc:1269
> >6100331A thread_stub(void *) debug.cc:91
> >77F04EE8 ?? ??:0
>
> I've added some more code to the snapshots in an attempt to work
> around this problem. I don't know if I was successful or not. It's
> hard to fix a problem when you can't duplicate it.
I know, and I appreciate your trying to fix it anyway! Unfortunately
I'm still unable to come up with a reproducible testcase -- the
most reliable failure I have is still once in every four or five times,
and deep inside a large shell script at that. :-(
I will try to test the new snapshot sooner rather than later; I had
a look just now, but the latest snapshot (2000-Sep-29) doesn't
seem to include anything "obvious". Is this the one I should try,
or will the changes be in the next snapshot build?
Thanks,
Andy
--
Andy Mortimer, CFX Software Development
andy.mortimer@aeat.com
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send: wait for sig_complete event failed
2000-09-19 10:13 Mortimer, Andy
@ 2000-09-19 10:41 ` Chris Faylor
0 siblings, 0 replies; 16+ messages in thread
From: Chris Faylor @ 2000-09-19 10:41 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
On Tue, Sep 19, 2000 at 06:10:35PM +0100, Mortimer, Andy wrote:
>Hi Chris/list,
>
>Chris Faylor writes:
>>On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
>>>1184486202 [sig] bash 28849 sig_send: wait for sig_complete
>>> event failed, sig 11, rc 258, Win32 error 0
>>
>>I don't know what is causing this but I can see that there is
>>apparently a SIGSEGV in cygwin's signal handling thread.
>>
>>I've made a change to recent snapshots which will cause cygwin to core
>>dump in this situation rather than try to send a signal to itself which
>>is never caught.
>>
>>If you have the time, please try out a snapshot.
>
>As noted in another message, the latest snapshots didn't work for me,
>but I've applied just the patch referred to here and it has indeed
>stopped the hang. Thanks, Chris! Now, I'm just left with the problem
>of bash segfaulting inside Cygwin's signal handling thread ... ;-)
Are you saying that you took the changes from the snapshot, applied them
to 1.1.4 sources, and rebuilt a DLL?
Unfortunately, I can't decipher a snapshot if you're using a home grown
DLL unless you're willing to tell me what all of the 6100* addresses
resolve to symbolically.
For that you can use 'addr2line' or gdb.
Btw, the argv[0] problem should be fixed in the next snapshot.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: sig_send: wait for sig_complete event failed
@ 2000-09-19 10:13 Mortimer, Andy
2000-09-19 10:41 ` Chris Faylor
0 siblings, 1 reply; 16+ messages in thread
From: Mortimer, Andy @ 2000-09-19 10:13 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
Hi Chris/list,
Chris Faylor writes:
> On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
> >1184486202 [sig] bash 28849 sig_send: wait for sig_complete
> > event failed, sig 11, rc 258, Win32 error 0
>
> I don't know what is causing this but I can see that there is
> apparently
> a SIGSEGV in cygwin's signal handling thread.
>
> I've made a change to recent snapshots which will cause
> cygwin to core dump
> in this situation rather than try to send a signal to itself
> which is never
> caught.
>
> If you have the time, please try out a snapshot.
As noted in another message, the latest snapshots didn't
work for me, but I've applied just the patch referred to
here and it has indeed stopped the hang. Thanks, Chris!
Now, I'm just left with the problem of bash segfaulting
inside Cygwin's signal handling thread ... ;-)
The stackdumps I'm getting are as included below, if it
helps anybody (the stack trace itself is different each time,
but the two lines I've prefixed with an asterisk are always
the same). As noted in a previous thread ("version
2.04-1 of bash crashing", 25 August this year), it does
seem to be inside the stack dumping code that it is giving
this core, but more than that I'm not really qualified to
tell. :-( Is this a known bug? If not, is there anything I
can do to help debug it[1]?
Thanks,
Andy
[1] Much as I'd love to provide a useful, small test case,
I can't find one. :-( This seems to happen intermittently,
in the course of running a large set of long and nested
shell scripts, and I've so far failed to reduce it down to
much less than an hour ... I noticed the other poster
also mentioned "running 6 bash shells with scripts all
at the same time." I'll pass it on if I do!
--
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com
*Exception: STATUS_ACCESS_VIOLATION at eip=6100922E
*eax=6107F7A8 ebx=6107F7A4 ecx=00000000 edx=00000000 esi=00000001 edi=0041BB04
ebp=1446F9F4 esp=1446FC94 program=C:\Cygwin\bin\bash.exe
*cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame Function Args
1446F9F4 6100922E (00000000, 00000000, 00000000, 00000000)
1446FCAC 6100922E (6107F7A4, 00000001, 77F88000, 77F60000)
1446FCDC 6100A2A3 (00000001, 00000014, 1446FEFC, 0041BB04)
1446FDEC 6100A806 (00000014, 1446FEFC, 0041BB04, 00000000)
1446FF0C 6100AF00 (00000014, 00000014, 00000000, 000001F4)
1446FF6C 6103EE0E (00000000, 1446FFB8, 610032F8, 1446FFB0)
1446FFB8 6100331A (6107F440, 6174736E, 68536C6C, 6107F440)
1446FFEC 77F04EE8 (610032D0, 61082020, 77366377, 000003F3)
End of stack trace
[An automatic footer will be attached to this message. By posting to a
public mailing list, I implicitly give permission to read/disclose/copy
/delete/reply to/whatever the message.]
***********************************************************************
This transmission contains information which may be confidential and
which may also be privileged. It is intended for the named addressee
only. Unless you are the named addressee, or authorised to receive it
on behalf of the addressee you may not copy or use it, or disclose it
to anyone else. If you have received this transmission in error please
contact the sender. Thank you for your cooperation.
***********************************************************************
For more information about AEA Technology please visit our website at http://www.aeat.co.uk
AEA Technology plc registered office 329 Harwell, Didcot, Oxfordshire OX11 0QJ.
Registered in England and Wales, number 3095862.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send: wait for sig_complete event failed
2000-09-15 4:04 Mortimer, Andy
@ 2000-09-18 10:57 ` Chris Faylor
0 siblings, 0 replies; 16+ messages in thread
From: Chris Faylor @ 2000-09-18 10:57 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
On Fri, Sep 15, 2000 at 12:01:52PM +0100, Mortimer, Andy wrote:
>I've just bitten the bullet and upgraded from a b20.1 snapshot release to the
>latest and greatest net release, and almost everything is much improved (so I
>don't really want to go back ... ;-) Unfortunately, I've started having various
>problems with the error message:
>
>1184486202 [sig] bash 28849 sig_send: wait for sig_complete event failed, sig 11, rc 258, Win32 error 0
I don't know what is causing this but I can see that there is apparently
a SIGSEGV in cygwin's signal handling thread.
I've made a change to recent snapshots which will cause cygwin to core dump
in this situation rather than try to send a signal to itself which is never
caught.
If you have the time, please try out a snapshot.
cgf
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: sig_send: wait for sig_complete event failed
@ 2000-09-15 5:57 Mortimer, Andy
0 siblings, 0 replies; 16+ messages in thread
From: Mortimer, Andy @ 2000-09-15 5:57 UTC (permalink / raw)
To: 'Earnie Boyd', 'cygwin@sources.redhat.com'
Hi Earnie,
[I assume you like mailing list CCs, since you CCd me, but feel free to note otherwise :-]
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> --- "Mortimer, Andy" <andy.mortimer@aeat.co.uk> wrote:
> > 1184486202 [sig] bash 28849 sig_send: wait for sig_complete
> > event failed, sig
> > 11, rc 258, Win32 error 0
> >
> -8<-
> > 603k 1999/06/03 E:\Tools\CYGWIN32_NT\bin\cygwinb19.dll -
> os=4.0 img=1.0
> > sys=4.0
> > "cygwinb19.dll" v0.0 ts=1998/6/7 18:35
> > Use -h to see help about each section
> >
>
> You've two differing versions of Cygwin on your path. This
> is the cause of
> your failure.
Sorry, I should probably have anticipated this reply and mentioned that explicitly! It's not actually another version of Cygwin, just an old DLL file which is no longer used by anything. Given that it has a different name, it can't be loaded by mistake ... I'll definitely try removing it, but I fear it won't help. The only thing in that directory which is used during the builds is a copy of b19 make recompiled with b20.1, but since I understand that 1.1.4 is backwards-compatible, I hadn't worried about that. I've deleted that too, although it's not failing until a while after the makes. We shall see!
Thanks, though, I should have tried that already! :-/
Andy
--
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com
$ rm /E/tools/CYGWIN32_NT/bin/cygwinb19.dll
$ \ls /E/tools/CYGWIN32_NT/bin/
banner.exe isoinfo.exe rshd.exe
cextract.exe isovfy.exe tcl80.dll
cvs.exe mkisofs.exe tclsh80.exe
devdump.exe mpeg_encode.exe tk80.dll
et2c.exe mpeg_play.exe wish80.exe
isodump.exe ndiff.exe xlib.dll.whyisthishere
$ dumpbin /imports $(cygpath -w /E/tools/CYGWIN32_NT/bin/)/* | grep -i cygwin | grep -v 'Dump of' | grep -i '\.dll'
cygwin1.dll
cygwin1.dll
cygwin1.dll
cygwin1.dll
cygwin1.dll
cygwin1.dll
cygwin1.dll
[An automatic footer will be attached to this message. By posting to a public
mailing list, I implicitly give permission to read/disclose/copy/delete/reply
to/whatever the message.]
***********************************************************************
This transmission contains information which may be confidential and
which may also be privileged. It is intended for the named addressee
only. Unless you are the named addressee, or authorised to receive it
on behalf of the addressee you may not copy or use it, or disclose it
to anyone else. If you have received this transmission in error please
contact the sender. Thank you for your cooperation.
***********************************************************************
For more information about AEA Technology please visit our website at http://www.aeat.co.uk
AEA Technology plc registered office 329 Harwell, Didcot, Oxfordshire OX11 0QJ.
Registered in England and Wales, number 3095862.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send: wait for sig_complete event failed
@ 2000-09-15 5:10 Earnie Boyd
0 siblings, 0 replies; 16+ messages in thread
From: Earnie Boyd @ 2000-09-15 5:10 UTC (permalink / raw)
To: Mortimer, Andy, 'cygwin@sources.redhat.com'
--- "Mortimer, Andy" <andy.mortimer@aeat.co.uk> wrote:
> Hi List,
>
> I've just bitten the bullet and upgraded from a b20.1 snapshot release to the
>
> latest and greatest net release, and almost everything is much improved (so I
>
> don't really want to go back ... ;-) Unfortunately, I've started having
> various
> problems with the error message:
>
> 1184486202 [sig] bash 28849 sig_send: wait for sig_complete event failed, sig
> 11, rc 258, Win32 error 0
>
-8<-
> 586k 2000/08/04 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
> "cygwin1.dll" v0.0 ts=2000/8/4 1:53
> Cygwin DLL version info:
> dll major: 1001
> dll minor: 4
> dll epoch: 19
> dll bad signal mask: 19005
> dll old termios: 5
> api major: 0
> api minor: 26
> shared data: 3
> dll identifier: cygwin1
> mount registry: 2
> cygnus registry name: Cygnus Solutions
> cygwin registry name: Cygwin
> program options name: Program Options
> cygwin mount registry name: mounts v2
> build date: Thu Aug 3 20:53:46 EDT 2000
> CVS tag: cygwin-1-1-4
> shared id: cygwin1S3
>
> 603k 1999/06/03 E:\Tools\CYGWIN32_NT\bin\cygwinb19.dll - os=4.0 img=1.0
> sys=4.0
> "cygwinb19.dll" v0.0 ts=1998/6/7 18:35
> Use -h to see help about each section
>
You've two differing versions of Cygwin on your path. This is the cause of
your failure.
Cheers,
=====
--- < http://earniesystems.safeshopper.com > ---
Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
__Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
__Minimalist GNU for Windows__
Mingw Home: < http://www.mingw.org/ >
__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* sig_send: wait for sig_complete event failed
@ 2000-09-15 4:04 Mortimer, Andy
2000-09-18 10:57 ` Chris Faylor
0 siblings, 1 reply; 16+ messages in thread
From: Mortimer, Andy @ 2000-09-15 4:04 UTC (permalink / raw)
To: 'cygwin@sources.redhat.com'
Hi List,
I've just bitten the bullet and upgraded from a b20.1 snapshot release to the
latest and greatest net release, and almost everything is much improved (so I
don't really want to go back ... ;-) Unfortunately, I've started having various
problems with the error message:
1184486202 [sig] bash 28849 sig_send: wait for sig_complete event failed, sig 11, rc 258, Win32 error 0
being repeated over and over and over. I've tried killing bash (PID 28849 in this case) with the kill command, but it doesn't seem to help. I couldn't work out
what its Windows PID was to try killing it from the Task Manager.
This is being given by our overnight rebuild and regression tests, which are
monster Bourne-shell and bash scripts, after a good few hours of runtime. I've
done a search of the mailing list archives, and the only other person I could find
who was seeing this was in the following message, during testing something
Tcl/Tk-ish: http://www.delorie.com/archives/browse.cgi?p=cygwin/2000/07/16/14:15:38
The same error message occurred in a couple of other contexts, but this was
the only one with a real-looking signal number and Win32 error 0. Needless to
say, I couldn't find a fix recorded with any of them. :-(
I haven't tried to run with strace and so on, for the simple reason that this only
seems to happen after they've been running pretty solidly for 4-5 hours or
more! I can't seem to find an obvious reproducible and useful test case, so it's
not obvious what anybody can do about it; this is mostly a plea for help! Has
anybody else seen this problem, and was there a solution?
This is NT 4, but with lots of software installed which may be causing this; I did
some tests using VMware before upgrading, and didn't see the problem, but I
was doing shorter runs there, and also the virtual machine is much slower than
a real NT box. I wonder whether it might be a race; I'm running on a dual CPU
box here, and that's caused me some problems before with stock b20.1. (In
that case, they were fixed by a snapshot). It's also interesting that I've been
having similar hangs with b20.1; I couldn't find any error messages in that case,
but it may or may not be related.
cygcheck output appended. Thanks in advance for any help/clues anybody can
give! (Especially if there is a way to recover from this and kill off the process
which is hung without having to start all the way over again, that'd be nice). If
anybody can give me a pointer as to where I might start debugging this I may
be able to have a go at that, but given what little I know about either this
problem or Cygwin, it's a rather daunting task at the moment!
Cheers,
Andy
--
Andy Mortimer, CFX-5 Architecture and Infrastructure Team
andy.mortimer@aeat.com
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Fri Sep 15 11:42:53 2000
WinNT Ver 4.0 build 1381 Service Pack 5
Path: /cygdrive/u/bin
/usr/local/bin
/usr/bin
/usr/bin
/c/Program Files/Microsoft Visual Studio/Common/Tools
/c/Program Files/Microsoft Visual Studio/Common/Msdev98/BIN
/c/Program Files/Microsoft Visual Studio/DF98/BIN
/c/Program Files/Microsoft Visual Studio/VC98/BIN
/c/Program Files/DevStudio/SharedIDE/BIN
/c/Program Files/DevStudio/DF/BIN
/c/Program Files/DevStudio/VC/BIN
/c/WINNT/system32
/c/WINNT
/c/Program Files/InstallShield/InstallShield 5.5 Professional Edition/Program
/c/Program Files/Exceed.nt
/e/Tools/CYGWIN32_NT/perl/bin/MSWin32-x86
/e/Tools/CYGWIN32_NT/perl/bin
/e/Tools/CYGWIN32_NT/bin
//CFX-SERVER/export/home_sd/Andy_Mortimer/Software/vim
//CFX-SERVER/export/home_sd/Andy_Mortimer/bin
/e/Tools/CYGWIN32_NT/perl/bin/MSWin32-x86
/e/Tools/CYGWIN32_NT/perl/bin
/e/Tools/CYGWIN32_NT/bin
//CFX-SERVER/export/home_sd/Andy_Mortimer/Software/vim
//CFX-SERVER/export/home_sd/Andy_Mortimer/bin
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
HOME = `/cygdrive/u'
MAKE_MODE = `unix'
PWD = `/E/Home/andy/src/tools/pvm-merge/pvm3'
USER = `andy_mortimer'
!C: = `C:\cygwin\bin'
!U: = `U:\'
CFXCVS_USER_LEVEL = `expert'
COMPUTERNAME = `XENON'
COMSPEC = `C:\WINNT\system32\cmd.exe'
CPU = `i386'
CVS_HOST = `io'
EDITMODE = `emacs'
EDITOR = `vim'
FPS_INCLUDE = `C:\FPS4\INCLUDE'
FPS_LIB = `C:\FPS4\LIB;C:\Program Files\DevStudio\VC\LIB'
FPS_PATH = `C:\FPS4\BIN'
HOMEDRIVE = `U:'
HOMEPATH = `\'
HOMESHARE = `\\cfx-server\Andy_Mortimer$'
HOSTNAME = `XENON'
HOSTTYPE = `i586'
INCLUDE = `C:\Program Files\Microsoft Visual Studio\DF98\INCLUDE;C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE;C:\Program Files\DevStudio\DF\INCLUDE;C:\Program Files\DevStudio\VC\INCLUDE'
LIB = `C:\Program Files\Microsoft Visual Studio\DF98\LIB;C:\Program Files\Microsoft Visual Studio\VC98\LIB;C:\Program Files\DevStudio\DF\LIB;C:\Program Files\DevStudio\VC\LIB'
LM_LICENSE_FILE = `C:\MSC\flexlm\licenses\license.dat'
LOGONSERVER = `\\CFX-SERVER'
MACHTYPE = `i586-pc-cygwin'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/cygdrive/u'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `cygwin'
PAGER = `less'
PATHEXT = `.COM;.EXE;.BAT;.CMD'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0502'
PROMPT = `$P$G'
PS1 = `\[\033]2;${SHDESC:+<$SHDESC>:}\w\007\033]1;<${SHDESC:-??}> \h:\W\007\]\[\033[1m\][${SHDESC:+$SHDESC:}$SHLVL]:\w\$\[\033[0m\] '
SHELL = `/bin/sh'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `/c/TEMP'
TERM = `cygwin'
USERDOMAIN = `CFX-UK'
USERNAME = `Andy_Mortimer'
USERPROFILE = `C:\WINNT\Profiles\andy_mortimer'
VISUAL = `vim'
WINDIR = `C:\WINNT'
_ = `/usr/bin/cygcheck'
TZ = `GMTST0GMTDT-1,M3.5.0/2,M10.5.0/3'
HKEY_CURRENT_USER\Console\cygnus.bat
(default) = 0x00000007
PopupColors = 0x000000f5
ColorTable00 = 0x00000000
ColorTable01 = 0x00800000
ColorTable02 = 0x00008000
ColorTable03 = 0x00808000
ColorTable04 = 0x00000080
ColorTable05 = 0x00800080
ColorTable06 = 0x00008080
ColorTable07 = 0x00c0c0c0
ColorTable08 = 0x00808080
ColorTable09 = 0x00ff0000
ColorTable10 = 0x0000ff00
ColorTable11 = 0x00ffff00
ColorTable12 = 0x000000ff
ColorTable13 = 0x00ff00ff
ColorTable14 = 0x0000ffff
ColorTable15 = 0x00ffffff
InsertMode = 0x00000001
QuickEdit = 0x00000001
FullScreen = 0x00000000
ScreenBufferSize = 0x0bb80050
WindowSize = 0x00190050
FontSize = 0x000c0000
FontFamily = 0x00000036
FontWeight = 0x00000190
FaceName = `Lucida Console'
CursorSize = 0x00000019
HistoryBufferSize = 0x00000032
NumberOfHistoryBuffers = 0x00000004
HistoryNoDup = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
(default) = `E:\Temp'
unix = `/tmp'
fbinary = 0x00000000
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
(default) = `\\colossus\scratch'
unix = `/scratch'
fbinary = 0x00000001
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
(default) = `E:\localscratch'
unix = `/localscratch'
fbinary = 0x00000000
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
(default) = `\\.\tape1:'
unix = `/dev/st1'
fbinary = 0x00000000
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
(default) = `\\.\tape0:'
unix = `/dev/st0'
fbinary = 0x00000000
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
(default) = `\\.\b:'
unix = `/dev/fd1'
fbinary = 0x00000000
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
(default) = `\\.\a:'
unix = `/dev/fd0'
fbinary = 0x00000000
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
(default) = `C:\Cygnus\Cygwin-b20\H-i586-cygwin32'
unix = `/'
fbinary = 0x00000000
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\&Programs\Cygnus Solutions
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\&Programs\Cygnus Solutions\Menu
(default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:/cygwin'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
(default) = `c:'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
(default) = `d:'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/e
(default) = `E:'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/f
(default) = `f:'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/g
(default) = `g:'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:/cygwin/bin'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:/cygwin/lib'
flags = 0x00000008
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
(default) = `c:\cygnus\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnus Cygwin B20
(default) = `C:\WINNT\IsUninst.exe -fc:\cygnus\cygwin-b20\Uninst.isu'
DisplayName = `Cygwin B20'
a: fd N/A N/A
c: hd NTFS 4008Mb 83% CP CS UN PA FC
d: cd CDFS 544Mb 100% CS DN60AENU2
e: hd NTFS 13350Mb 73% CP CS UN PA FC
f: cd N/A N/A
g: hd NTFS 17508Mb 69% CP CS UN PA FC
j: net NTFS 2047Mb 0% CP CS home_devel
t: net NTFS 31047Mb 99% CP CS UN PA FC User space
u: net NTFS 31047Mb 99% CP CS UN PA FC User space
C:\cygwin\bin /usr/bin system textmode
C:\cygwin\lib /usr/lib system textmode
C:\cygwin / system textmode
E: /e system textmode
c: /c system textmode
d: /d system textmode
f: /f system textmode
g: /g system textmode
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: E:\Tools\CYGWIN32_NT\bin\make.exe
Warning: C:\cygwin\bin\make.exe hides E:\Tools\CYGWIN32_NT\bin\make.exe
Found: C:\cygwin\bin\sh.exe
83k 2000/06/11 C:\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
"cygitcl30.dll" v0.0 ts=2000/6/11 4:34
35k 2000/06/11 C:\cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
"cygitk30.dll" v0.0 ts=2000/6/11 4:34
402k 2000/06/11 C:\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=2000/6/11 4:30
5k 2000/06/11 C:\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
10k 2000/06/11 C:\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=2000/6/11 4:30
639k 2000/06/11 C:\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=2000/6/11 4:34
586k 2000/08/04 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=2000/8/4 1:53
Cygwin DLL version info:
dll major: 1001
dll minor: 4
dll epoch: 19
dll bad signal mask: 19005
dll old termios: 5
api major: 0
api minor: 26
shared data: 3
dll identifier: cygwin1
mount registry: 2
cygnus registry name: Cygnus Solutions
cygwin registry name: Cygwin
program options name: Program Options
cygwin mount registry name: mounts v2
build date: Thu Aug 3 20:53:46 EDT 2000
CVS tag: cygwin-1-1-4
shared id: cygwin1S3
603k 1999/06/03 E:\Tools\CYGWIN32_NT\bin\cygwinb19.dll - os=4.0 img=1.0 sys=4.0
"cygwinb19.dll" v0.0 ts=1998/6/7 18:35
Use -h to see help about each section
[An automatic footer will be attached to this message. By posting to a public
mailing list, I implicitly give permission to read/disclose/copy/delete/reply
to/whatever the message.]
***********************************************************************
This transmission contains information which may be confidential and
which may also be privileged. It is intended for the named addressee
only. Unless you are the named addressee, or authorised to receive it
on behalf of the addressee you may not copy or use it, or disclose it
to anyone else. If you have received this transmission in error please
contact the sender. Thank you for your cooperation.
***********************************************************************
For more information about AEA Technology please visit our website at http://www.aeat.co.uk
AEA Technology plc registered office 329 Harwell, Didcot, Oxfordshire OX11 0QJ.
Registered in England and Wales, number 3095862.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send(): wait for sig_complete event failed...
1998-11-26 11:26 ` Victor Ott
1998-12-02 19:49 ` John Alvord
@ 1998-12-19 8:33 ` John Alvord
1 sibling, 0 replies; 16+ messages in thread
From: John Alvord @ 1998-12-19 8:33 UTC (permalink / raw)
To: gnu-win32
A quick followup. The B20.1 binaries do not exhibit the sig_send
message noticed in B20.
John Alvord
Music, Management, Poetry and more...
http://www.candlelist.org/kuilema
Cheap CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send(): wait for sig_complete event failed...
1998-11-26 11:26 ` Victor Ott
@ 1998-12-02 19:49 ` John Alvord
1998-12-19 8:33 ` John Alvord
1 sibling, 0 replies; 16+ messages in thread
From: John Alvord @ 1998-12-02 19:49 UTC (permalink / raw)
To: Victor Ott; +Cc: gnu-win32
I am getting this message at the end of makefile processing. I use
MAKE_MODE=unix so sh.exe is the shell. This is on B20, never saw the
problem on B19.1.
This is on NT4SP3. The message occurs about one third the time and all
procesing seems to be completed successfully.
John Alvord
Music, Management, Poetry and more...
http://www.candlelist.org/kuilema
Cheap CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: sig_send(): wait for sig_complete event failed...
1998-11-24 21:59 sig_send(): " Eric Barton
@ 1998-11-26 11:26 ` Victor Ott
1998-12-02 19:49 ` John Alvord
1998-12-19 8:33 ` John Alvord
0 siblings, 2 replies; 16+ messages in thread
From: Victor Ott @ 1998-11-26 11:26 UTC (permalink / raw)
To: gnu-win32
Eric Barton wrote:
>
> I've just installed B20 (under NT4.0 SP3 on a Pentium PRO) and I get the
> following problem with executing a shell script from cmd.exe...
>
> d:\>: bash /bin/which which
> [proc] c:\bin\sh.exe 1006 (0) sig_send: wait for sig_complete event failed, sig
> 20, rc -1, error 6
> [proc] c:\bin\sh.exe 1009 (0) sig_send: wait for sig_complete event failed, sig
> 20, rc -1, error 6
> [proc] c:\bin\sh.exe 1012 (0) sig_send: wait for sig_complete event failed, sig
> 20, rc -1, error 6
> [proc] c:\bin\sh.exe 1015 (0) sig_send: wait for sig_complete event failed, sig
> 20, rc -1, error 6
> /bin/which
[...]
B20, NT4SP3
I'm getting a similar error (see below) when CYGWIN contains 'tty' and
bash ist started from desktop or cmd. The offending code is in my /.bashrc
and it's the `` evaluation.
cygnuspath="/cygwin-b20/H-i586-cygwin32/bin"
PATH=.:$cygnuspath:`echo $PATH | sed -e
"s@/cygwin-b20/H-i586-cygwin32/bin@@g"`
Whitout 'tty' (" notty notitle glob ntea") the error appeared only once
(some hours ago :) in a makefile:
{ compile -g -i$(INCDIR) setup.rul; \
echo $$? > $$TMP/make.$$$$; \
} | grep -v "W7503"; \
ret_val=`cat $$TMP/make.$$$$`; rm $$TMP/make.$$$$; \
[ "$$ret_val" = "0" ]
## error ###################
C:\work\is\installs\master>set CYGWIN= tty
C:\work\is\installs\master>bash
[proc] C:\cygwin-b20\H-i586-cygwin32\bin\bash.exe 1020 (0) sig_send: wait
for sig_complete event failed, sig 20, rc -1, error 6
############################
Thanks in advance for any help,
Victor
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 16+ messages in thread
* sig_send(): wait for sig_complete event failed...
@ 1998-11-24 21:59 Eric Barton
1998-11-26 11:26 ` Victor Ott
0 siblings, 1 reply; 16+ messages in thread
From: Eric Barton @ 1998-11-24 21:59 UTC (permalink / raw)
To: gnu-win32
I've just installed B20 (under NT4.0 SP3 on a Pentium PRO) and I get the
following problem with executing a shell script from cmd.exe...
d:\>: bash /bin/which which
[proc] c:\bin\sh.exe 1006 (0) sig_send: wait for sig_complete event failed, sig
20, rc -1, error 6
[proc] c:\bin\sh.exe 1009 (0) sig_send: wait for sig_complete event failed, sig
20, rc -1, error 6
[proc] c:\bin\sh.exe 1012 (0) sig_send: wait for sig_complete event failed, sig
20, rc -1, error 6
[proc] c:\bin\sh.exe 1015 (0) sig_send: wait for sig_complete event failed, sig
20, rc -1, error 6
/bin/which
d:\>
Executing the same thing in an emacs shell (using cmdproxy) just hangs with
100% CPU. Executing the same command line from an interactive bash session
works OK. "which" is the following shell script...
#!/bin/sh
all=0
showpath=0
while getopts ap c; do
case $c in
a) all=1;;
p) showpath=1;;
*) ;;
esac
done
shift `expr $OPTIND - 1`
if [ $showpath = 1 ]; then
echo $PATH | awk -F: '{for(i=1;i<=NF;i++)printf"%s\n",$i;}'
exit 0
fi
xpath=`echo $PATH | sed -e 's/ /_un9likely_/g' | sed -e 's/:/ /g'`
for x in $*; do
# cmd="`alias $x`"
# if [ "$cmd" = "" ]; then
cmd="$x"
# else
# echo "${x}: aliased to $cmd"
# cmd=`alias $x | awk '{print $1}'`
# fi
for p in $xpath; do
p=`echo $p | sed -e 's/_un9likely_/ /g'`
if [ -x "$p/${cmd}" ]; then
echo $p/${cmd}
if [ $all = 0 ]; then
break
fi
fi
done
done
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2001-12-31 0:42 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-20 3:27 sig_send: wait for sig_complete event failed Mortimer, Andy
2000-09-30 10:17 ` Chris Faylor
-- strict thread matches above, loose matches on Subject: below --
2001-12-31 1:15 paul
2000-10-05 2:51 Mortimer, Andy
2000-10-02 4:50 Mortimer, Andy
2000-10-02 8:47 ` Chris Faylor
2000-09-19 10:13 Mortimer, Andy
2000-09-19 10:41 ` Chris Faylor
2000-09-15 5:57 Mortimer, Andy
2000-09-15 5:10 Earnie Boyd
2000-09-15 4:04 Mortimer, Andy
2000-09-18 10:57 ` Chris Faylor
1998-11-24 21:59 sig_send(): " Eric Barton
1998-11-26 11:26 ` Victor Ott
1998-12-02 19:49 ` John Alvord
1998-12-19 8:33 ` John Alvord
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).