Re: accept: Bad address

On Wed, Apr 04, 2018 at 11:25:30AM +0200, Corinna Vinschen wrote: > I reshuffled lots of socket code to make room for a new AF_UNIX > implementation. While at it, I screwed up in a few places, so > socket code was broken for a bit. The OpenSSH testsuite helped > a lot to find the bugs, btw :} >

accept: Bad address

Hello, The latest Cygwin 64-bit release with the snapshot cygwin1.dll copied on top of it shows an "accept: Bad address error" in 3 reproducible cases: (a) The sshd daemon on receiving a connection request. (b) The XWin server on receiving a connection request from an X11 client such as xterm.

Re: Cannot start Bash after today's update

> This looks very strange, almost impossible. Did you still have Cygwin > processes running, services maybe, while you updated? Indeed, I forgot to stop cygrunsrv and sshd. When I saw your question I ran ProcessExplorer64, turned on the view of all processes but could not find cygrunsrv, sshd

Cannot start Bash after today's update

> C:\Users\USER>\cygwin\bin\bash.exe > 0 [main] bash 6784 C:\cygwin\bin\bash.exe: *** fatal error - add_item > ("㽜尿㩃捜杹楷n", "/", ...) failed, errno 1 > Stack trace: > Frame Function Args > 002888D8 6102F96B (002888D8, , , ) > 00288BC8 6102F96B (61

Re: hard-coded library search path in gcc-4

>> $ ( export PATH= ; /cygdrive/c/cygwin/bin/gcc-4.exe -v -E - < /dev/null ) I figured that cc1 depends on /usr/bin.  A user invoking cc1 directly could figure the missing dependency.  Invoking cc1 indirectly from /usr/bin/gcc-4 without /usr/bin in PATH will break cc1 against expectation of

hard-coded library search path in gcc-4

I found that gcc-4 from a recent setup.exe could not start cc1 because the latter could not find some shared object file. I confirmed that by running cc1 alone with an empty PATH variable. > $ ( export PATH= ; /cygdrive/c/cygwin/bin/gcc-4.exe -v -E - < /dev/null ) > Using built-in specs. > COL

update on tr feasibility in text mode docs

The current documentation on Cygwin text mode heuristic relies on a bug in a GNU tool. That bug was fixed. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/doc/textbinary.sgml?rev=1.11&content-type=text/x-cvsweb-markup&cvsroot=src The script will not work on a text mounted systems b

Re: often does not successfully exit rxvt and close it down

> Anybody else? Same here. I am even ruling out any interference with programs I launch from the terminal. Last time I noticed, even running a couple of Perforce commands made it impossible to shut the terminal on exit. Also, during long ant builds I notice that the build would pause. My pr

1.7.1: cvs version built in is unstable

> I check out a module of my repository (located on a remote machine) > and a handful of files do not get downloaded due to the "no such file" > error described below. Try "cvs up -d" or delete everything and "cvs co" anew. I could not check out the new directory with a simple "cvs up" myself

Re: allow executing a path in backslash notation

> I checked this situation in cmd.exe, and it is not capable of using > paths relativ to %Path%. In other words, if %Path% contains a path > c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe, > then calling "baz" works, but calling "bar\baz" fails. I only meant resolving relati

Re: allow executing a path in backslash notation

> This has been changed deliberately, otherwise > the execp functions have a potential security problem. If you omit the > NNF flag, the function returns the original path unchanged, instead of > NULL. I see that my conjecture about the root cause of the observed inconsistency was incorrect. B

Re: allow executing a path in backslash notation

> constness of pointers Err, I meant constness of rvalue. But this is not related. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsu

Re: allow executing a path in backslash notation

On Mar 10 10:25, Corinna Vinschen wrote: > execv (argv[1], args); > bash$ gcc -o exec exec.c > bash$ ./exec /bin/echo > abc > bash$ ./exec C:\\cygwin\\bin\\echo > abc Thanks for trying a test case. I am attaching a new test case that shows that the trouble was with execvp(), not exec().

Re: allow executing a path in backslash notation

> The bottom line is that if you want to use MS-DOS > paths, then use a MinGW or DJGPP version of make.exe. make.exe is not > going to be patched. The patch was to cygwin1.dll, but I am not insisting. -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://c

allow executing a path in backslash notation

The attached patch allows executing a path in backslash notation. This can be tested in the Cygwin builds of GNU make with the "DOS compatibility" compile-time option of GNU make enabled, such as those from Cygwin make packages 3.79 and 3.80. $ cat dos-compat.mak default: ..\echo.exe

Re: Cygwin build scripts in perl

>>In particular, mkimport ran objcopy against "ftruncate.o" in a >>temporary directory, but I believe the expected filename argument was >>supposed to be "t-ftruncate.o". This is only my conjecture as I do not >>know the purpose and the intention of the implementation with these >>scripts. >Whil

Re: Cygwin build scripts in perl

> It isn't clear from your email what you are attempting to accomplish but > it sounds like you are trying to build cygwin using a non-cygwin-aware > version of perl. If that is the case, then this is not of interest to > the project or this mailing list. The build breaks were exposed by using

Cygwin build scripts in perl

(a) I found that winsup/cygwin/mkimport specified non-existent file names as arguments to objcopy invocations. I am not sure why this did not cause build breaks earlier. (b) It appears perl 5.6 and, possibly, perl 5.10 do not implement the "list form of pipe" in calls to "open()", open $my

Re: CreateProcess() - executed program gets different argument depending if it's compiled with gcc (cygwin) or cl (VS)?

> Thanks to your createprocess.c/dumpargs.c pair, I could figure the existing > Cygwin's parsing without looking into its source code. It turned to ignore > the > escaping power of a bare (unquoted) backslash when it was followed by a > double > quote, which is against both MSVC and Bash

Re: CreateProcess() - executed program gets different argument depending if it's compiled with gcc (cygwin) or cl (VS)?

> As you can see dumpargs_gcc receives "\127.0.0.127\foo.cxx" and dumpargs_cl > receives "\\127.0.0.127\foo.cxx". Interesting. I am confused, too. (1) Native-only parameter passing: execv(PROG, ARGV) -> MSVCRT -> line = M(ARGV) -> CreateProcess( PROG, line, .. ) -> MSVC

a bug in a week old mmap

$ gdb --args perl -i -pe 's/\r//g' f.txt GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRAN

a bug in cygpath

This caused Cygwin to run dumper.exe which pointed to a bug in cygpath.cc. $ cygpath -p -w '' I am attaching a patch that seems to have fixed the issue. -- Index: cygpath.cc ===

execute a file in backslash notation from shell

It never occurred to me that shells are unable to execute their first word in the Windows native backslash format, $ 'c:\cygwin\bin\echo.exe' test bash: c:\cygwin\bin\echo.exe: command not found $ ls -la 'c:\cygwin\bin\echo.exe' -rwxr-xr-x 1 ilatypov Domain Users 48128 2008-12-17 1

Re: document side effects of incomplete implementations in regtool and cyglsa-config, suggest a manual restore procedure

> * Safe boot locks up after loading the last driver service such as ksecdd, > wudfpf, ntfs, ndis, sisagp, viaagp, alim1541, agpamd, agp440, agpcpq. + mup.sys -- Index: ntsec.sgml === RCS file: /cvs/src/src/winsup/doc/ntsec.sg

Re: document side effects of incomplete implementations in regtool and cyglsa-config, suggest a manual restore procedure

> I spent many hours trying to find the cause of these effects. Forgot to mention another side effect: * Safe boot locks up after loading the last driver service such as ksecdd, wudfpf, ntfs, ndis, sisagp, viaagp, alim1541, agpamd, agp440, agpcpq.Index: ntsec.sgml ===

document side effects of incomplete implementations in regtool and cyglsa-config, suggest a manual restore procedure

The current cyglsa-config script does not detect a failure in regtool that cannot read the LSA Authentication Packages registry entry, $ regtool get /HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Lsa/Authentication\ Packages Error (2): The system cannot find the file specified. $