Re: cygutils Postinstall Script Errors With Exit Code 128

[dylanhay]

exit  code 128
  
Generally, this kind of failure stems from a few common problems:

  1. The existence of another (often old) cygwin1.dll.  Find it.  Remove it.
  2. http://cygwin.com/acronyms/#BLODA.  Remove BLODA.
  3. Possibly fork failures.  Install the rebase package and run
 rebaseall after reading the README in /usr/share/doc/Cygwin.


Also, make sure you're using the latest 'setup.exe' as found at cygwin.com.
Beware of proxies along your path that could be caching an old version.
You want version 2.697.


Problem reports: http://cygwin.com/problems.html 


If it's none of the above, please provide cygcheck output as requested by
the link above.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Re-cygutils-Postinstall-Script-Errors-With-Exit-Code-128-tp99002p109846.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: pipe handling errors

[Christopher Faylor]

On Tue, Jul 15, 2014 at 06:05:27PM -0400, Christopher Faylor wrote:
>Yes, I saw that, but I can't duplicate the problem with that command sequence.

I took a stab at another change which may ameliorate the problem.  Please
try the latest snapshot.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: pipe handling errors

[Christopher Faylor]

On Tue, Jul 15, 2014 at 08:40:32PM +, Nellis, Kenneth wrote:
>From: Christopher Faylor
>>On Tue, Jul 15, 2014 at 07:17:48PM +, Nellis, Kenneth wrote:
>>>From: Nellis, Kenneth
>>>
>>>> Well, I'm getting different results with the latest snapshot. 
>>>> Instead of getting the error message, I'm getting a hang for maybe a 
>>>> minute before it continues.
>>>> 
>>>> I used the following command to encourage a failure:
>>>> 
>>>> clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f 
>>>> ===; strings $f | grep '\.cpp$' | sort | uniq -c | sort -n; done
>>>
>>>
>>>Thought it might be useful to add that I can fairly easily get the same 
>>>minute-long hang with a simpler command:
>>>
>>>Cygwin64> strings *Subsystem | wc -l
>>
>>What's your cwd when you run this command?
>
>Well, it *was* on a network drive, but that appears to be irrelevant:
>
>Cygwin64> date; seq 1 | wc -l; date
>Tue Jul 15 16:31:52 EDT 2014
>1
>Tue Jul 15 16:32:52 EDT 2014
>Cygwin64> pwd
>/home/knellis
>Cygwin64> cygpath -w $PWD
>C:\cygwin\home\knellis
>Cygwin64> uname -srvmo
>CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
>Cygwin64>

Yes, I saw that, but I can't duplicate the problem with that command sequence.

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: pipe handling errors

[Nellis, Kenneth]

From: Christopher Faylor
>On Tue, Jul 15, 2014 at 07:17:48PM +, Nellis, Kenneth wrote:
>>From: Nellis, Kenneth
>>
>>> Well, I'm getting different results with the latest snapshot. 
>>> Instead of getting the error message, I'm getting a hang for maybe a minute 
>>> before it continues.
>>> 
>>> I used the following command to encourage a failure:
>>> 
>>> clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f 
>>> ===; strings $f | grep '\.cpp$' | sort | uniq -c | sort -n; done
>>
>>
>>Thought it might be useful to add that I can fairly easily get the same 
>>minute-long hang with a simpler command:
>>
>>Cygwin64> strings *Subsystem | wc -l
>
>What's your cwd when you run this command?

Well, it *was* on a network drive, but that appears to be irrelevant:

Cygwin64> date; seq 1 | wc -l; date
Tue Jul 15 16:31:52 EDT 2014
1
Tue Jul 15 16:32:52 EDT 2014
Cygwin64> pwd
/home/knellis
Cygwin64> cygpath -w $PWD
C:\cygwin\home\knellis
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>

--Ken Nellis

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: pipe handling errors

[Christopher Faylor]

On Tue, Jul 15, 2014 at 07:17:48PM +, Nellis, Kenneth wrote:
>From: Nellis, Kenneth
>
>> Well, I'm getting different results with the latest snapshot. 
>> Instead of getting the error message, I'm getting a hang for maybe a minute 
>> before it continues.
>> 
>> I used the following command to encourage a failure:
>> 
>> clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f ===; 
>> strings $f | grep '\.cpp$' | sort | uniq -c | sort -n; done
>
>
>Thought it might be useful to add that I can fairly easily get the same 
>minute-long hang with a simpler command:
>
>Cygwin64> strings *Subsystem | wc -l

What's your cwd when you run this command?

cgf

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: pipe handling errors

[Nellis, Kenneth]

At the risk of annoying folks uninterested in this problem,
here is a simpler test case:

Cygwin64> date; seq 1 | wc -l; date
Tue Jul 15 15:30:03 EDT 2014
1
Tue Jul 15 15:31:03 EDT 2014
Cygwin64>

The output ("1") occurs immediately and then the hang
for precisely one minute before the 2nd date.

As before:

Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>

--Ken Nellis

RE: pipe handling errors

[Nellis, Kenneth]

From: Nellis, Kenneth

> Well, I'm getting different results with the latest snapshot. 
> Instead of getting the error message, I'm getting a hang for maybe a minute 
> before it continues.
> 
> I used the following command to encourage a failure:
> 
> clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f ===; 
> strings $f | grep '\.cpp$' | sort | uniq -c | sort -n; done


Thought it might be useful to add that I can fairly easily get the same 
minute-long hang with a simpler command:

Cygwin64> strings *Subsystem | wc -l

--Ken Nellis

RE: pipe handling errors

[Nellis, Kenneth]

From: Corinna Vinschen
> Hi Kenneth,
> 
> On Jul 15 13:50, Nellis, Kenneth wrote:
> > From: Corinna Vinschen
> > > On Jul 14 17:40, Nellis, Kenneth wrote:
> > > > When running a bash pipeline using the latest 64-bit packages, I 
> > > > occasionally get output like the following:
> > > > 
> > > > 1479561950 [waitproc] -bash 1 sig_send: error sending signal 
> > > > 20, pipe handle 0x2710, nb 132, packsize 0, Win32 error 109
> > > > 
> > > 
> > > 
> > > I know that we got this message more often in the past, but I'm 
> > > totally unable to reproduce it these days.  I tried with 1.7.30 as 
> > > well as the latest snapshots.
> > > 
> > > I'm wondering if a pipe could be intercepted by a virus checker or 
> > > something like that.  Whatever it is, would you mind to give the 
> > > latest developer snapshot DLL (2014-07-15) from 
> > > http://cygwin.com/snapshots/ a try?  Chris has fixed a typo in the 
> > > above debug message.  If it still happens for you, maybe the new output 
> > > helps better to find the cause.
> > 
> > FYI, got it again this morning, this time with the suggested snapshot:
> > 
> >   0 [main] -bash 8812 sig_send: error sending signal -66, pid 
> > 8812, pipe handle 0x80, nb 0, packsize 176, Win32 error 0
> > 
> > Cygwin64> uname -srvmo
> > CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 09:22:44 x86_64 Cygwin
> > Cygwin64>
> 
> Thanks.  I just created another snapshot which is supposed to fix this issue 
> (curtesy cgf).  Can you give it a try, please?

Well, I'm getting different results with the latest snapshot. Instead of 
getting the error message, I'm getting a hang for maybe a minute before it 
continues.

I used the following command to encourage a failure:

clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f ===; strings 
$f | grep '\.cpp$' | sort | uniq -c | sort -n; done

9 invocations of this resulted in 3 hangs. During the last such hang, 
ps output showed the following (from a 2nd mintty window):

Cygwin64> ps
  PIDPPIDPGID WINPID   TTY UIDSTIME COMMAND
 6268   111008800  10808  pty012779 14:41:03 /usr/bin/sort 

 181229681812  10924  pty112779 14:41:49 /usr/bin/ps
 2968   108402968  10340  pty112779 14:41:41 /usr/bin/bash
 5208   111008800   5212  pty012779 14:41:03 /usr/bin/grep 

11196   1   11196  11196  ?   12779 14:37:15 /usr/bin/mintty
 7752   111008800  10324  pty012779 14:41:03 /usr/bin/sort 

10840   1   10840  10840  ?   12779 14:41:41 /usr/bin/mintty
11100   11196   11100   6260  pty012779 14:37:15 /usr/bin/bash
 9536   111008800  10368  pty012779 14:41:03 /usr/bin/uniq 

Cygwin64>

After it completed, it showed the following

Cygwin64> ps
  PIDPPIDPGID WINPID   TTY UIDSTIME COMMAND
 2968   108402968  10340  pty112779 14:41:41 /usr/bin/bash
103162968   10316   3152  pty112779 14:42:08 /usr/bin/ps
11196   1   11196  11196  ?   12779 14:37:15 /usr/bin/mintty
10840   1   10840  10840  ?   12779 14:41:41 /usr/bin/mintty
I   11100   11196   11100   6260  pty012779 14:37:15 /usr/bin/bash
Cygwin64>

Just to confirm I was using the later snapshot:
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>

--Ken Nellis

Re: timeout in LDAP access

[Andrey Repin]

Greetings, Denis Excoffier!

>>> A POSIX offset of 0 is bad.  If other trusted domains have no functional
>>> POSIX offset value, but are set to 0 instead, they won't have different
>>> UID values for accounts of different domains.  Two users from different
>>> domains, both with RID 1000 will both have UID 1000 in Cygwin.  Also,
>>> the lower UID numbers are reserved for special accounts.
>>> 
>>> There is no guarantee that there won't be a collision at some point of
>>> the 32 bit UID spectrum, but a POSIX offset of 0 will almost guarantee
>>> the collision.

> Independently, i’m still not sure we have to workaround IT "madness" at all. 
> First, IT
> people might set PosixOffset to 1 for each domain and you cannot catch this 
> kind
> of alternate madness. Also, be sure that if some user someday suffers from a 
> duplicate
> UID situation, this will be reported to them and hopefully addressed (or not 
> because
> this might be expected), but most probably for a single domain. We have to 
> live with
> PosixOffset=0.

I'd say, setting up your AD with zero offset is as bad, as using
192.168.0.1/24 network (or any other well known range) for VPN connections.
I don't think this is a situation that should be attempted to fix from client
side.
What we really need here is a comprehensive explanation of the issue and a
suggested way to remedy it at the root.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 15.07.2014, <22:08>

Sorry for my terrible english...

Re: timeout in LDAP access

[Denis Excoffier]

On 2014-07-14 15:48 Corinna Vinschen wrote:
> On Jul 14 11:51, Corinna Vinschen wrote:
>> On Jul 12 15:39, Denis Excoffier wrote:
>>> On 2014-07-09 12:12 Corinna Vinschen wrote:
> 
> I have encountered this case in real life. The domain admins have set
> the trustPosixOffset of the secondary domain to zero. This value is 
> therefore
> never recorded and the cldap->open occurs again and again.
 
 Ouch.  Why on earth are admins doing this?  There's no way to
 workaround this reliably.
 
>>> Reliably i don’t know. I’ve modified uinfo.cc in order that the special 
>>> value
>>> for td->PosixOffset is no longer 0. Taking into account that 
>>> LDAP_SERVER_DOWN
>>> is now recognized, my ‘getent passwd’ executes gracefully in 40 minutes
>>> (instead of 60) and ‘getent group’ in 25 minutes (instead of 90). Also 
>>> quicker
>>> is ‘mkpasswd -d secondary_domain’ of course. Patch attached.
>> 
>> That won't work.  It works around your immediate problem by defining
>> a non-0 start value, no doubt about that, but it doesn't fix the
>> underlying problem.
>> 
>> A POSIX offset of 0 is bad.  If other trusted domains have no functional
>> POSIX offset value, but are set to 0 instead, they won't have different
>> UID values for accounts of different domains.  Two users from different
>> domains, both with RID 1000 will both have UID 1000 in Cygwin.  Also,
>> the lower UID numbers are reserved for special accounts.
>> 
>> There is no guarantee that there won't be a collision at some point of
>> the 32 bit UID spectrum, but a POSIX offset of 0 will almost guarantee
>> the collision.
>> 
>> There are two ways to workaround that.
>> 
>> - The better solution is to inform your IT of the problem.
>> 
>> - The not so well one is to enhance /etc/nsswitch.conf to allow to
>>  define POSIX offsets for domains indepedent of the AD setting.
> 
> I tried the third solution for the time being, which is, generating the
> fake POSIX offset a bit differently.  Fake offsets are a bit dangerous
> in that there's no guarantee that you get a stable mapping between SID
> and UID/GID, but it's *hopefully* a border situation we're trying to
> workaround.  Please give the latest developer snashot from
> http://cygwin.com/snapshots/ a try.
Tried and it works as expected. However there is a design bug. Suppose you
have a SID from a non-primary domain (with PosixOffset=0). When you enumerate,
you get a PosixOffset that takes into account the previously encountered
secondary domains with PosixOffset=0, say you get UNIX_POSIX_OFFSET-3*0x0080

But you can also jump directly to the non-primary domain of this SID, eg by
‘getent passwd SID’. In this case you get UNIX_POSIX_OFFSET-0x0080.

In fact, real code is a little bit more complex, but you get the point:
‘getent passwd’ and ‘getent passwd SID’ will not give the same UID for a given 
SID,
the AD remaining unmodified.

Independently, i’m still not sure we have to workaround IT "madness" at all. 
First, IT
people might set PosixOffset to 1 for each domain and you cannot catch this kind
of alternate madness. Also, be sure that if some user someday suffers from a 
duplicate
UID situation, this will be reported to them and hopefully addressed (or not 
because
this might be expected), but most probably for a single domain. We have to live 
with
PosixOffset=0.

Yet, under the assumption that PosixOffsets are not modified by Cygwin, previous
uinfo.cc (snapshot dated 20140709) is not so efficient when
PosixOffset=0 (eg too many connect’s), and i think my patch makes a better 
Cygwin
than with no patch. Probably it can also be improved to remove the special 
value.

Regards,

Denis Excoffier.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: How to mount all network drives noacl

[Larry Hall (Cygwin)]

On 07/15/2014 11:59 AM, Lemke, Michael SZ/HZA-ZSW wrote:

On 15 Jul 2014 17:30:40 +0200,
Corinna Vinschen wrote:

On Jul 15 15:24, Lemke, Michael  SZ/HZA-ZSW wrote:

I am sure this is described somewhere but I (or rather google) can't find it:

What to put into /etc/fstab to make any access to a network share use
the noacl option? E.g. cp ... //server1/path should create all files
with default Windows permissions on the remote end, same for //server2/path2 
etc.


It's all in the cygdrive prefix:

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive



Thanks, I would never have seen that.  So the answer is

none / cygdrive binary,posix=0,user,noacl 0 0

But that would also make my local drives not use acls, which I don't want.
So is there a solution to have UNC paths use noacl and drives with a drive
letter use acl?


Yes but you'll need to mount the network drives that you want to use noacl
individually.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: How to mount all network drives noacl

[Lemke, Michael SZ/HZA-ZSW]

On 15 Jul 2014 17:30:40 +0200, 
Corinna Vinschen wrote:
>On Jul 15 15:24, Lemke, Michael  SZ/HZA-ZSW wrote:
>> I am sure this is described somewhere but I (or rather google) can't find it:
>>
>> What to put into /etc/fstab to make any access to a network share use
>> the noacl option? E.g. cp ... //server1/path should create all files
>> with default Windows permissions on the remote end, same for //server2/path2 
>> etc.
>
>It's all in the cygdrive prefix:
>
>  https://cygwin.com/cygwin-ug-net/using.html#cygdrive
>

Thanks, I would never have seen that.  So the answer is

none / cygdrive binary,posix=0,user,noacl 0 0

But that would also make my local drives not use acls, which I don't want.
So is there a solution to have UNC paths use noacl and drives with a drive
letter use acl?

Thanks,
Michael


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: pipe handling errors

[Corinna Vinschen]

Hi Kenneth,

On Jul 15 13:50, Nellis, Kenneth wrote:
> From: Corinna Vinschen
> > On Jul 14 17:40, Nellis, Kenneth wrote:
> > > When running a bash pipeline using the latest 64-bit packages, I 
> > > occasionally get output like the following:
> > > 
> > > 1479561950 [waitproc] -bash 1 sig_send: error sending signal 20, 
> > > pipe handle 0x2710, nb 132, packsize 0, Win32 error 109
> > > 
> > 
> > 
> > I know that we got this message more often in the past, but I'm totally 
> > unable to reproduce it these days.  I tried with 1.7.30 as well as the
> > latest snapshots.
> > 
> > I'm wondering if a pipe could be intercepted by a virus checker or 
> > something 
> > like that.  Whatever it is, would you mind to give the latest developer 
> > snapshot DLL (2014-07-15) from http://cygwin.com/snapshots/ a try?  Chris 
> > has fixed a typo in the above debug message.  If it still happens for you, 
> > maybe the new output helps better to find the cause.
> 
> FYI, got it again this morning, this time with the suggested snapshot:
> 
>   0 [main] -bash 8812 sig_send: error sending signal -66, pid 8812, pipe 
> handle 0x80, nb 0, packsize 176, Win32 error 0
> 
> Cygwin64> uname -srvmo
> CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 09:22:44 x86_64 Cygwin
> Cygwin64>

Thanks.  I just created another snapshot which is supposed to fix this
issue (curtesy cgf).  Can you give it a try, please?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp3RFwjVtKX4.pgp
Description: PGP signature

Re: How to mount all network drives noacl

[Corinna Vinschen]

On Jul 15 15:24, Lemke, Michael  SZ/HZA-ZSW wrote:
> I am sure this is described somewhere but I (or rather google) can't find it:
> 
> What to put into /etc/fstab to make any access to a network share use
> the noacl option? E.g. cp ... //server1/path should create all files
> with default Windows permissions on the remote end, same for //server2/path2 
> etc.

It's all in the cygdrive prefix:

  https://cygwin.com/cygwin-ug-net/using.html#cygdrive


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpdfotGlyypE.pgp
Description: PGP signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

On Jul 15 16:45, Jan Nijtmans wrote:
> 2014-07-15 16:39 GMT+02:00 Corinna Vinschen:
> > On Jul 15 21:55, JonY wrote:
> >> On 7/15/2014 21:08, Corinna Vinschen wrote:
> >> >>
> >> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 
> >> >> 4.8.2-2.
> >> >
> >> > JonY, do you have a chance to have a look into this issue?
> >> >
> >>
> >> Sorry, I have been busy these few weeks, but I am well aware that there
> >> is a problem with one of the libgcc changes, but has yet to investigate it.
> >>
> >> I believe Jon Turney has looked into it somewhat.
> >
> > Sounds good.  Thanks in advance.
> 
> Is this essentially the same problem as described here?
> 
> 

I just read the entire thread and it looks pretty much like what we see
here.  Eli Zaretskii's analysis of the crash is very enlightening and
seems to hit the nail on its head, but unfortunately there was never any
reply from the guys maintaining the Windows parts of gcc :(


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpRvU4vNhhqE.pgp
Description: PGP signature

How to mount all network drives noacl

[Lemke, Michael SZ/HZA-ZSW]

I am sure this is described somewhere but I (or rather google) can't find it:

What to put into /etc/fstab to make any access to a network share use
the noacl option? E.g. cp ... //server1/path should create all files
with default Windows permissions on the remote end, same for //server2/path2 
etc.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Jan Nijtmans]

2014-07-15 16:39 GMT+02:00 Corinna Vinschen:
> On Jul 15 21:55, JonY wrote:
>> On 7/15/2014 21:08, Corinna Vinschen wrote:
>> >>
>> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
>> >
>> > JonY, do you have a chance to have a look into this issue?
>> >
>>
>> Sorry, I have been busy these few weeks, but I am well aware that there
>> is a problem with one of the libgcc changes, but has yet to investigate it.
>>
>> I believe Jon Turney has looked into it somewhat.
>
> Sounds good.  Thanks in advance.

Is this essentially the same problem as described here?



Regards,
   Jan Nijtmans

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

On Jul 15 21:55, JonY wrote:
> On 7/15/2014 21:08, Corinna Vinschen wrote:
> >>
> >> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> > 
> > JonY, do you have a chance to have a look into this issue?
> > 
> 
> Sorry, I have been busy these few weeks, but I am well aware that there
> is a problem with one of the libgcc changes, but has yet to investigate it.
> 
> I believe Jon Turney has looked into it somewhat.

Sounds good.  Thanks in advance.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgptlH8E5eSvx.pgp
Description: PGP signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[JonY]

On 7/15/2014 21:08, Corinna Vinschen wrote:
>>
>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.
> 
> JonY, do you have a chance to have a look into this issue?
> 

Sorry, I have been busy these few weeks, but I am well aware that there
is a problem with one of the libgcc changes, but has yet to investigate it.

I believe Jon Turney has looked into it somewhat.




signature.asc
Description: OpenPGP digital signature

RE: pipe handling errors

[Nellis, Kenneth]

From: Corinna Vinschen
> On Jul 14 17:40, Nellis, Kenneth wrote:
> > When running a bash pipeline using the latest 64-bit packages, I 
> > occasionally get output like the following:
> > 
> > 1479561950 [waitproc] -bash 1 sig_send: error sending signal 20, 
> > pipe handle 0x2710, nb 132, packsize 0, Win32 error 109
> > 
> 
> 
> I know that we got this message more often in the past, but I'm totally 
> unable to reproduce it these days.  I tried with 1.7.30 as well as the
> latest snapshots.
> 
> I'm wondering if a pipe could be intercepted by a virus checker or something 
> like that.  Whatever it is, would you mind to give the latest developer 
> snapshot DLL (2014-07-15) from http://cygwin.com/snapshots/ a try?  Chris 
> has fixed a typo in the above debug message.  If it still happens for you, 
> maybe the new output helps better to find the cause.

FYI, got it again this morning, this time with the suggested snapshot:

  0 [main] -bash 8812 sig_send: error sending signal -66, pid 8812, pipe 
handle 0x80, nb 0, packsize 176, Win32 error 0

Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 09:22:44 x86_64 Cygwin
Cygwin64>

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Houder]

>> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

> JonY, do you have a chance to have a look into this issue?

Trying to help ...

- test program
#include 
#include 

//int main (int argc, char **argv)
int main (int argc, char *argv[])
{
  HMODULE m = LoadLibrary (argv[1]);
  if (!m)
printf ("%s: %lu\n", argv[1], GetLastError ());
  else
printf ("Success.\n");
// 15/07/2014: currently resulting in a crash on 32-bits only (gcc only)
  return 0;
}
-

The test program above fails (abort) for every cyg*.dll in /usr/bin that pulls 
in cyggcc_s-1.dll.

(if not, the test program exits normally)

(using the same compiler and cygwin1.dll as Ken did)

H.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

On Jul 15 07:45, Ken Brown wrote:
> On 7/15/2014 5:02 AM, Corinna Vinschen wrote:
> >On Jul 14 19:42, Ken Brown wrote:
> >>I'm getting a core dump on exit from a program that does nothing but call
> >>dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
> >>case.  Here's a simple test case.
> >>
> >>$ cat test_dlopen.c
> >>#include 
> >>#include 
> >>int
> >>main()
> >>{
> >>   const char *dllname = "cyggs-9.dll";
> >>   void *handle;
> >>   printf ("Trying to dlopen %s...", dllname);
> >>   handle = dlopen (dllname, RTLD_LAZY);
> >>   if (handle)
> >> {
> >>   printf ("succeeded.\n");
> >>   return 0;
> >> }
> >>   else
> >> {
> >>   printf ("failed.\n");
> >>   return 1;
> >> }
> >>}
> >>
> >>$ gcc test_dlopen.c
> >>
> >>$ ./a
> >>Trying to dlopen cyggs-9.dll...succeeded.
> >>Aborted (core dumped)
> >
> >The crash occurs when calling the destructors from do_global_dtors.
> >The crash address points to a crash inside a destructor of libgcc
> >(actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.
> >
> >What destructor in libgcc would that be?  And what is it expecting
> >which is apparently missing?
> 
> FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

JonY, do you have a chance to have a look into this issue?


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgplHOF1SPD0Q.pgp
Description: PGP signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Ken Brown]

On 7/15/2014 5:02 AM, Corinna Vinschen wrote:

On Jul 14 19:42, Ken Brown wrote:

I'm getting a core dump on exit from a program that does nothing but call
dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
case.  Here's a simple test case.

$ cat test_dlopen.c
#include 
#include 
int
main()
{
   const char *dllname = "cyggs-9.dll";
   void *handle;
   printf ("Trying to dlopen %s...", dllname);
   handle = dlopen (dllname, RTLD_LAZY);
   if (handle)
 {
   printf ("succeeded.\n");
   return 0;
 }
   else
 {
   printf ("failed.\n");
   return 1;
 }
}

$ gcc test_dlopen.c

$ ./a
Trying to dlopen cyggs-9.dll...succeeded.
Aborted (core dumped)


The crash occurs when calling the destructors from do_global_dtors.
The crash address points to a crash inside a destructor of libgcc
(actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.

What destructor in libgcc would that be?  And what is it expecting
which is apparently missing?


FWIW, the problem disappears if I revert gcc-core and libgcc1 to 4.8.2-2.

Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: pipe handling errors

[Corinna Vinschen]

On Jul 14 17:40, Nellis, Kenneth wrote:
> When running a bash pipeline using the latest 64-bit packages, 
> I occasionally get output like the following:
> 
> 1479561950 [waitproc] -bash 1 sig_send: error sending signal 20, pipe 
> handle 0x2710, nb 132, packsize 0, Win32 error 109
> 
> That one was the result of: strings  | grep  | sort | 
> uniq -c
> 
> Here's a different one that I got twice when sending "strings" 
> output to "grep" and once sending "strings" output to "wc -l":
> 
> 605884587 [main] -bash 1 sig_send: error sending signal -66, pipe handle 
> 0x2710, nb 132, packsize 0, Win32 error 0
> 
> I haven't found them to be repeatable.
> 
> I just tried on 32-bit Cygwin and got the following twice in a row, 
> but not a third time, so I suspect a race condition.
> 
>   1 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 
> 0x2538, nb 152, packsize 0, Win32 error 0
> 25098461 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 
> 0x2538, nb 152, packsize 0, Win32 error 0
> 
> The initial "1" on the first one looks interesting. 
> This one also was: strings  | grep 
> 
> The common element in all these examples was generating the pipeline data
> with "strings". I don't recall whether strings was always involved or not.
> 
> Not a big concern because the generated output looks correct, 
> but a tad annoying. Thought it worth reporting.
> 
> FWIW, on 64-bit:
> Cygwin64> uname -a
> CYGWIN_NT-6.1 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin
> Cygwin64> cygcheck -f `which strings`
> binutils-2.24.51-4
> Cygwin64>
> 
> On 32-bit:
> Cygwin32> uname -a
> CYGWIN_NT-6.1-WOW64 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin
> Cygwin32> cygcheck -f `which strings`
> binutils-2.24.51-4
> Cygwin32>

I know that we got this message more often in the past, but I'm totally
unable to reproduce it these days.  I tried with 1.7.30 as well as the
latest snapshots.

I'm wondering if a pipe could be intercepted by a virus checker or
something like that.  Whatever it is, would you mind to give the latest
developer snapshot DLL (2014-07-15) from http://cygwin.com/snapshots/ a
try?  Chris has fixed a typo in the above debug message.  If it still
happens for you, maybe the new output helps better to find the cause.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgph1WyHqxrQ3.pgp
Description: PGP signature

Re: Core dump on 32-bit Cygwin if program calls dlopen

[Corinna Vinschen]

On Jul 14 19:42, Ken Brown wrote:
> I'm getting a core dump on exit from a program that does nothing but call
> dlopen.  (But the call to dlopen succeeds.)  This happens only in the 32-bit
> case.  Here's a simple test case.
> 
> $ cat test_dlopen.c
> #include 
> #include 
> int
> main()
> {
>   const char *dllname = "cyggs-9.dll";
>   void *handle;
>   printf ("Trying to dlopen %s...", dllname);
>   handle = dlopen (dllname, RTLD_LAZY);
>   if (handle)
> {
>   printf ("succeeded.\n");
>   return 0;
> }
>   else
> {
>   printf ("failed.\n");
>   return 1;
> }
> }
> 
> $ gcc test_dlopen.c
> 
> $ ./a
> Trying to dlopen cyggs-9.dll...succeeded.
> Aborted (core dumped)

The crash occurs when calling the destructors from do_global_dtors.
The crash address points to a crash inside a destructor of libgcc
(actually cyggcc_1-1.dll) which has been pulled in by cyggs-9.dll.

What destructor in libgcc would that be?  And what is it expecting
which is apparently missing?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp4ToUPKTfb3.pgp
Description: PGP signature

Re: Typo in snapshots /usr/include/cygwin/version.h

[Corinna Vinschen]

On Jul 15 02:12, Andrey Repin wrote:
> Greetings, All!
> 
> +  273: Introduce account mapping from WIndows account DBs.  Add 
> CW_SETENT,
> ^ erroneous capital "i".

Fixed.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgp4nVzWiSfPC.pgp
Description: PGP signature