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

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 r

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

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() > { > co

Re: pipe handling errors

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 on

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

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

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

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 s

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

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

RE: pipe handling errors

> 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

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

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

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 t

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

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 h

How to mount all network drives noacl

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

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

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

Re: How to mount all network drives noacl

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

Re: pipe handling errors

gt; > 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 snapsh

RE: How to mount all network drives noacl

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

Re: How to mount all network drives noacl

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 n

Re: timeout in LDAP access

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 seco

Re: timeout in LDAP access

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

RE: pipe handling errors

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 &

RE: pipe handling errors

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 '*Subsyst

RE: pipe handling errors

inute 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

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

RE: pipe handling errors

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

Re: pipe handling errors

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

Re: pipe handling errors

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

Re: cygutils Postinstall Script Errors With Exit Code 128

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