Re: cygwin1.dll > 3.1.4: Program execution fails if (WSL-)symlink exists and is present in PATH
On Dec 2 15:05, Corinna Vinschen wrote: > On Dec 2 13:39, Takashi Yano via Cygwin wrote: > > On Tue, 1 Dec 2020 19:13:39 -0500 > > Ken Brown via Cygwin wrote: > > > On 12/1/2020 4:24 AM, Mattl Mario wrote: > > > > Hello, > > > > > > > > Since cygwin1.dll version 3.1.5, I observed the following behavior: > > > > If a symbolic link is existing in the PATH environment, programs > > > > (external from Cygwin's system directory) using cygwin1.dll cannot be > > > > executed anymore. > > > > Possibly, because the Cygwin-DLL isn't found anymore. > > > > > > > > Steps to reproduce: > > > > > > > > cd / > > > > mkdir link_test > > > > cp /usr/bin/sed.exe link_test > > > > ln -s link_test test > > > > export PATH=/test:/link_test:/usr/bin:/bin > > > > > > > > /link_test/sed cannot be executed > > > > $ ldd /link_test/sed > > > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > > > > (0x7d96) > > > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > > > (0x7d14) > > > > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > > > > (0x7a8e) > > > > SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL > > > > (0x550c) > > > > > > > > -> no cygwin- DLLs found > > > > [...] > > > I think this was fixed by commit > > > 4b4fffe0f2390be6a5be27b6a3ceaa212a3724b2, but I > > > don't have time to check carefully, and I'm going to be AFK for a few > > > days > > > starting tomorrow. > > > > I can reproduce this issue with current git head even with > > the commit 4b4fffe0f2390be6a5be27b6a3ceaa212a3724b2. > > Just looking into it. It has something to do with missing to resolve > a WSL symlinks to a Windows path, but I'm not sure yet where this occurs. I pushed a patch and uploaded new developer snapshots to https://cygwin.com/snapshots/ Please give it a try. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin1.dll > 3.1.4: Program execution fails if (WSL-)symlink exists and is present in PATH
On Dec 3 18:30, Takashi Yano via Cygwin wrote: > On Wed, 2 Dec 2020 16:35:02 +0100 > Corinna Vinschen via Cygwin wrote: > > On Dec 2 15:05, Corinna Vinschen wrote: > > > On Dec 2 13:39, Takashi Yano via Cygwin wrote: > > > > On Tue, 1 Dec 2020 19:13:39 -0500 > > > > Ken Brown via Cygwin wrote: > > > > > On 12/1/2020 4:24 AM, Mattl Mario wrote: > > > > > > Hello, > > > > > > > > > > > > Since cygwin1.dll version 3.1.5, I observed the following behavior: > > > > > > If a symbolic link is existing in the PATH environment, programs > > > > > > (external from Cygwin's system directory) using cygwin1.dll cannot > > > > > > be executed anymore. > > > > > > Possibly, because the Cygwin-DLL isn't found anymore. > > > > > > > > > > > > Steps to reproduce: > > > > > > > > > > > > cd / > > > > > > mkdir link_test > > > > > > cp /usr/bin/sed.exe link_test > > > > > > ln -s link_test test > > > > > > export PATH=/test:/link_test:/usr/bin:/bin > > > > > > > > > > > > /link_test/sed cannot be executed > > > > > > $ ldd /link_test/sed > > > > > > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll > > > > > > (0x7d96) > > > > > > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > > > > > > (0x7d14) > > > > > > KERNELBASE.dll => > > > > > > /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7a8e) > > > > > > SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL > > > > > > (0x550c) > > > > > > > > > > > > -> no cygwin- DLLs found > > > > > > [...] > > > > > I think this was fixed by commit > > > > > 4b4fffe0f2390be6a5be27b6a3ceaa212a3724b2, but I > > > > > don't have time to check carefully, and I'm going to be AFK for a few > > > > > days > > > > > starting tomorrow. > > > > > > > > I can reproduce this issue with current git head even with > > > > the commit 4b4fffe0f2390be6a5be27b6a3ceaa212a3724b2. > > > > > > Just looking into it. It has something to do with missing to resolve > > > a WSL symlinks to a Windows path, but I'm not sure yet where this occurs. > > > > I pushed a patch and uploaded new developer snapshots to > > https://cygwin.com/snapshots/ > > > > Please give it a try. > > I have confirmed that the issue has been resolved on current git head. Thanks for testing! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygwin1.dll > 3.1.4: Program execution fails if (WSL-)symlink exists and is present in PATH
On Dec 3 10:58, Mattl Mario wrote: > Hello everyone, > > I can confirm: > with the latest snapshot-DLL, it is working fine again. (as Corinna mentioned) Thanks for testing! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: tar 1.33 symlinks : Cannot change mode to...
On Jan 12 11:55, Ken Brown via Cygwin wrote:
> On 1/11/2021 6:50 PM, Ken Brown via Cygwin wrote:
> > On 1/11/2021 2:57 PM, Morgan King via Cygwin wrote:
> > > Hello,
> > >
> > > I am experiencing the same issue with tar and I am able to reproduce
> > > it following the steps at:
> > > https://lists.gnu.org/archive/html/bug-tar/2011-08/msg6.html
> > >
> > > This issue only appears to occur when using 32-bit Cygwin, I am
> > > unable to reproduce it using 64-bit Cygwin.
> >
> > I can confirm this. Running the tar command under gdb shows a problem
> > at gnu/fchmodat.c:94:
> >
> > 94 if (S_ISLNK (st.st_mode))
> >
> > Here st is a stat structure for directory/1, so S_ISLNK() should be
> > true. It is indeed true on 64-bit Cygwin but not on 32-bit Cygwin.
> > Someone needs to look more closely and find out why this happened. I'll
> > try to do it tomorrow if no one beats me to it.
>
> This appears to be a bug in fstat in 32-bit Cygwin. Here's what I'm seeing
> in gdb, using an unoptimized build of cygwin1.dll. There is a call to
> fstatat in the tar source file gnu/fchmodat.c:87. This ultimately leads to
> a call to fstat, whose definition in syscalls.cc is the following in the
> 32-bit case:
No, wait. struct stat == struct _stat64 since Cygwin 1.5.0!
With Cygwin 1.5.0, the old entry point fstat was only retained to serve
old 32 bit applications buil.t under Cygwin 1.3.x or earlier.
Consequentially, newer 32 bit apps, built with Cygwin 1.5.0 or later,
are redirected to fstat64, see NEW_FUNCTIONS in Makefile.in.
If tar is actually calling fstat, something fishy is going on.
> After the call to stat64_to_stat32, buf looks like this:
>
> (gdb) p/o *buf
> $22 = {st_dev = 026106753173, st_ino = 0175104120777, st_mode = 01001,
> st_nlink = 01, st_uid = 013777346014, st_gid = 03415154434,
> st_rdev = 013777334323, st_size = 0161040234413777346014, st_atim = {
> tv_sec = 020, tv_nsec = 0}, st_mtim = {tv_sec = 01, tv_nsec = 0},
> st_ctim = {tv_sec = 06533716, tv_nsec = 02500}, st_blksize = 0,
> st_blocks = 0, st_birthtim = {tv_sec = 0, tv_nsec = 03}}
>
> Note that many of the values have been corrupted or shifted.
NHo, they are not. The problme is jsut that buf is defined as
`struct stat' for API compatibility, but older (pre Cygwin-1.5.0)
32 bit apps expect the old 32 bit struct __stat32. Therefore,
to evaluate the content of buf correctly, you have to cast it to
struct __stat32 * in GDB. But... see above.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: tar 1.33 symlinks : Cannot change mode to...
On Jan 12 12:49, Ken Brown via Cygwin wrote: > On 1/12/2021 12:15 PM, Corinna Vinschen wrote: > > On Jan 12 11:55, Ken Brown via Cygwin wrote: > > > [...] > > > This appears to be a bug in fstat in 32-bit Cygwin. Here's what I'm > > > seeing > > > in gdb, using an unoptimized build of cygwin1.dll. There is a call to > > > fstatat in the tar source file gnu/fchmodat.c:87. This ultimately leads > > > to > > > a call to fstat, whose definition in syscalls.cc is the following in the > > > 32-bit case: > > > > No, wait. struct stat == struct _stat64 since Cygwin 1.5.0! > > > > With Cygwin 1.5.0, the old entry point fstat was only retained to serve > > old 32 bit applications buil.t under Cygwin 1.3.x or earlier. > > > > Consequentially, newer 32 bit apps, built with Cygwin 1.5.0 or later, > > are redirected to fstat64, see NEW_FUNCTIONS in Makefile.in. > > > > If tar is actually calling fstat, something fishy is going on. > > It's not tar that's calling fstat, it's Cygwin's fstatat at > syscalls.cc:4855. This appears to be a bug that I introduced in commit > 84252946. I'll fix it. Oh, right, this code should call fstat64, or resolve to an fhandler and call its fstat method. > Thanks for setting me straight. Never mind, shit happens. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: tar 1.33 symlinks : Cannot change mode to...
On Jan 13 11:52, Ken Brown via Cygwin wrote: > On 1/11/2021 2:57 PM, Morgan King via Cygwin wrote: > > Hello, > > > > I am experiencing the same issue with tar and I am able to reproduce it > > following the steps at: > > https://lists.gnu.org/archive/html/bug-tar/2011-08/msg6.html > > > > This issue only appears to occur when using 32-bit Cygwin, I am unable to > > reproduce it using 64-bit Cygwin. I need to use 32-bit Cygwin since I use a > > 32-bit application which depends on Cygwin. > > This turned out to be a Cygwin bug, which has now been fixed. As soon as > Corinna has a chance to upload new snapshots to > https://cygwin.com/snapshots/, you'll be able to test it. Snapshot is up! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 19:28, Takashi Yano via Cygwin wrote:
> On Fri, 2 Dec 2022 19:40:30 -0800
> Ilya Zakharevich wrote:
> > On Wed, Nov 16, 2022 at 04:48:25AM -0800, I wrote:
> > > De-quoting (converting the Windows’ command-line into argc/argv) does
> > > not remove double quotes if characters not fit for 8-bit (?) are present.
> > >
> > > To reproduce, do in CMD’s command line:
> > >
> > > D:\> D:\Programs\cygwin2022\bin\perl -wle "print for @ARGV" . "/i/"
> > > "/и/" .
> > > .
> > > /i/
> > > "/и/"
> > > .
> > [...]
> This certainly seems to be a problem of cygwin1.dll.
>
> Though I am not sure this is the right thing, I have confirmed
> that the following patch solves the issue.
>
> diff --git a/newlib/libc/locale/lctype.c b/newlib/libc/locale/lctype.c
> index 644669765..732d132e1 100644
> --- a/newlib/libc/locale/lctype.c
> +++ b/newlib/libc/locale/lctype.c
> @@ -25,11 +25,20 @@
>
> #define LCCTYPE_SIZE (sizeof(struct lc_ctype_T) / sizeof(char *))
>
> +#ifdef __CYGWIN__
> +static char numsix[] = { '\6', '\0'};
> +#else
> static char numone[] = { '\1', '\0'};
> +#endif
>
> const struct lc_ctype_T _C_ctype_locale = {
> +#ifdef __CYGWIN__
> + "UTF-8",/* codeset */
> + numsix /* mb_cur_max */
> +#else
> "ASCII",/* codeset */
> numone /* mb_cur_max */
> +#endif
Good idea, but this transforms the "C" locale into the "C.UTF-8" locale
once and for all.
What we're actually missing is a matching _C_utf8_ctype_locale which can
be used by Cygwin as default locale setting, AFAICS.
I pushed a patch and the test release is rebuilding while I type.
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 22:42, Takashi Yano via Cygwin wrote: > [...] > The patch above also affects __C_locale. > The patch below should be more appropriate. Looks like we had the same idea at the same time :) Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] tcsh 6.24.03-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.03-1 This is a bugfix release. 1. Handle \c in echo properly. 2. Add a configure check for a working sbrk(). 3. Fix a test failure on busybox. Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [BUG core?] Regression with parsing Windows’ command-line
On Dec 3 16:24, Corinna Vinschen via Cygwin wrote: > On Dec 3 19:28, Takashi Yano via Cygwin wrote: > > On Fri, 2 Dec 2022 19:40:30 -0800 > > Ilya Zakharevich wrote: > > > On Wed, Nov 16, 2022 at 04:48:25AM -0800, I wrote: > > > > De-quoting (converting the Windows’ command-line into argc/argv) does > > > > not remove double quotes if characters not fit for 8-bit (?) are > > > > present. > > > > > > > > To reproduce, do in CMD’s command line: > > > > > > > > D:\> D:\Programs\cygwin2022\bin\perl -wle "print for @ARGV" . "/i/" > > > > "/и/" . > > > > . > > > > /i/ > > > > "/и/" > > > > . > > > [...] > I pushed a patch and the test release is rebuilding while I type. This will be fixed in test release cygwin-3.4.0-0.875.g07a9a6c21ab3, which should be up in an hour or so. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.0-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.0-1 * cygwin-devel-3.4.0-1 * cygwin-doc-3.4.0-1 == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. == What's new: --- - Drop support for Vista and Server 2008. - Drop support for 32 bit Windows and WOW64. - Allow to run with full ASLR enabled and enable on Cygwin DLL by default. - Remove any special handling for the .com filename suffix. It has to be used always explicitely. - Add code to handle setrlimit(RLIMIT_AS). - Add code to handle signal masks in /proc//status. - Handle UDP_SEGMENT and UDP_GRO socket options. What changed: - - The CYGWIN=pipe_byte option is now set by default, so that pipes are opened in byte mode rather than message mode. Addresses: https://cygwin.com/pipermail/cygwin/2021-March/247987.html - The stdio input functions no longer try again to read after EOF. This aligns Cygwin behavior to that of Linux. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html - Treat an empty path (empty element in PATH or PATH is absent) as the current directory as Linux does. Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html - The default values of FD_SETSIZE and NOFILE are now 1024 and 3200, respectively. Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html Bug Fixes - - Don't error out if getfacl(1) is called on a socket file. Partially addresses: https://cygwin.com/pipermail/cygwin/2022-July/251768.html - Make serial ioctl(TIOCMBIS/TIOCMBIC) work on USB CDC devices. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252443.html - Fix a SEGV when running a process with changed primary group. Addresses: https://cygwin.com/pipermail/cygwin-apps/2022-September/042245.html - Fix primary group handling when running a process tree containing non-Cygwin processes and with changed primary group. The Cygwin child process of a non-Cygwin process will have reverted its primary group to the default primary group erroneously. Addresses: https://cygwin.com/pipermail/cygwin-apps/2022-September/042245.html - Fix parsing Windows command line when non-ASCII chars are in the input. Addresses: https://cygwin.com/pipermail/cygwin/2022-November/252481.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] tcsh 6.24.05-1
The following packages have been uploaded to the Cygwin distribution: * tcsh-6.24.05-1 This is a maintenance release with no functional change to the shell itself, but all additional changes from 6.24.03 (and 6.24.04, never released) have been applied to the manual page. All other changes are about the build and release processes. Downside: The conversion from the man page to HTML has been deprecated, so the HTML documentation is no longer part of this package. Tcsh is an enhanced but completely compatible version of csh, the C shell. Tcsh is a command language interpreter which can be used both as an interactive login shell and as a shell script command processor. Tcsh includes a command line editor, programmable word completion, spelling correction, a history mechanism, job control and a C language like syntax. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gcc -pg broken after cygwin update?
On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > Hi, > > This morning I updated cygwin, and after that gcc started producing errors > like this: > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg -DVERBOSE > > -c -o ../obj/.o .c > > gcc -o ../bin/ ../obj/.o -pg > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > ../obj/.o: in function `exit_eval_failure': > /home/daab/dev/someproj/src/.c:17: undefined reference to > `__fentry__' > > If I drop the "pg" flags from the compilation and linking stages, everything > works. > > I typically update cygwin packages once per week, but now it has been > maybe a month since I last updated. As far as I can tell from the > cygwin-announce archives, there has not been any gcc updates in that > period, but I do note that cygwin itself has been updated. Could that > be related? Thanks for the report. This is a dumb bug I introduced into the build system in 3.4.0. I fixed that in the git repo, but the automated build of the matching test release cygwin-3.5.0-0.17.g95f5b0a62036 is currently not building due to some hiccup on cygwin.com. I'll send a new mail as soon as this is fixed and you can test it (provided you run at least Windows 8.1). Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gcc -pg broken after cygwin update?
On Dec 7 12:50, Corinna Vinschen via Cygwin wrote: > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > > Hi, > > > > This morning I updated cygwin, and after that gcc started producing errors > > like this: > > > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg > > > -DVERBOSE -c -o ../obj/.o .c > > > gcc -o ../bin/ ../obj/.o -pg > > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > > ../obj/.o: in function `exit_eval_failure': > > /home/daab/dev/someproj/src/.c:17: undefined reference to > > `__fentry__' > > > > If I drop the "pg" flags from the compilation and linking stages, > > everything works. > > > > I typically update cygwin packages once per week, but now it has been > > maybe a month since I last updated. As far as I can tell from the > > cygwin-announce archives, there has not been any gcc updates in that > > period, but I do note that cygwin itself has been updated. Could that > > be related? > > Thanks for the report. > > This is a dumb bug I introduced into the build system in 3.4.0. I fixed > that in the git repo, but the automated build of the matching test > release cygwin-3.5.0-0.17.g95f5b0a62036 is currently not building due to > some hiccup on cygwin.com. I'll send a new mail as soon as this is > fixed and you can test it (provided you run at least Windows 8.1). Automated builds have been picked up again and the Cygwin test package 3.5.0-0.17.g95f5b0a62036 should be available later today. You can install it using setup.exe, just like any other test release. Don't forget to install the matching cygwin-devel package, too, that's the one containing the library libgmon.a, which is what gets linked in with `gcc -pg'. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 7 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > provided you run at least Windows 8.1 > > Why would that be a requirement? Test releases are created from the master branch which already bumped version to 3.5.0 and contains patches dropping W7 and W8 support: https://cygwin.com/pipermail/cygwin-announce/2022-December/010821.html Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: gcc -pg broken after cygwin update?
On Dec 7 15:05, Daniel Abrahamsson via Cygwin wrote: > > On Dec 7 12:50, Corinna Vinschen via Cygwin wrote: > > > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote: > > > > Hi, > > > > > > > > This morning I updated cygwin, and after that gcc started producing > > > > errors like this: > > > > > > > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg > > > > > -DVERBOSE -c -o ../obj/.o .c > > > > > gcc -o ../bin/ ../obj/.o -pg > > > > > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: > > > > > ../obj/.o: in function `exit_eval_failure': > > > > /home/daab/dev/someproj/src/.c:17: undefined reference to > > > > `__fentry__' > > > > [...] > > > Thanks for the report. > > > > > > This is a dumb bug I introduced into the build system in 3.4.0. I fixed > > > that in the git repo, but the automated build of the matching test > > > [...] > > Automated builds have been picked up again and the Cygwin test package > > 3.5.0-0.17.g95f5b0a62036 should be available later today. You can > > install it using setup.exe, just like any other test release. > > > > Don't forget to install the matching cygwin-devel package, too, that's > > the one containing the library libgmon.a, which is what gets linked in > > with `gcc -pg'. > > I can confirm 3.5.0-0.17.g95f5b0a62036 solves the issue with the "-pg" > flag. Thank you! Thanks for your feedback! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 7 17:59, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > contains patches dropping W7 and W8 support: > > Hmm... I understood that "dropping support" was not something that > would _require_ newer OS, but that it may not work (or not guaranteed > to work, patches not checked for compatibility, etc) on the older > OSes... Are you saying that W7 and W8 would be actively rejected? Supporting older OSes requires to keep workarounds in the code and sometimes leads to the inability to implement stuff in ways only available on newer OSes. Each deprecation of older OSes in Cygwin worked like this so far, and for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8 since the first 3.3.0 release in October 2021. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 8 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8 > > since the first 3.3.0 release in October 2021. > > I saw that. It did not look alarming. It basically was like "you'll be on > your own". > > > Supporting older OSes requires to keep workarounds in the code and > > Understood. But you did not answer my question: > > > Are you saying that W7 and W8 would be actively rejected? > > and I meant by Cygwin? Not "rejected" as such. It just won't run correctly anymore on W7/8, because - the special treatment required for those OSes isn't in the DLL anymore, and - the DLL uses functions not available on these OSes. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: gcc -pg broken after cygwin update?
On Dec 8 16:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry for pressing this, I must be slow today. > > > just won't run correctly anymore on W7/8 > > Won't or may not? Won't Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.1-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.1-1 * cygwin-devel-3.4.1-1 * cygwin-doc-3.4.1-1 This is a bugfix release. - Fix a backward incompatibility problem in the definition of the base type of the stdio type FILE. This requires that C++ binaries compiled under Cygwin 3.4.0 having a public facing interface using FILE need to be recompiled. Addresses: https://savannah.gnu.org/bugs/index.php?63480 - Fix an error introduced into the build process, resulting in `gcc -pg' becoming disfunctional. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252619.html - Fix performance degradation of non-cygwin pipe. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252628.html == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 There are no plans to deprecate support for 64 bit systems starting with Windows 8.1 / Windows Server 2012 R2 any time soon. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.2-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.2-1 * cygwin-devel-3.4.2-1 * cygwin-doc-3.4.2-1 This is a bugfix release. - Fix regression in uname(2), accidentally adding a leading dot to utsname::machine. == IMPORTANT DEPRECATION NOTES == - Cygwin 3.4 is the FIRST major version dropping support for - 32 bit Windows including WOW64 on 64 bit Windows. - Windows Vista - Windows Server 2008 - Cygwin 3.4 is the LAST major version supporting - Windows 7 - Windows Server 2008 R2 - Windows 8 - Windows Server 2012 - Cygwin 3.5, which will probably be release at some point in late 2023, will run on - Windows 8.1 - Windows 10 - Windows 11 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 - Windows Server 2022 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Regarding EFBIG error while opening a file using catopen() function
It's somewhat rude to send such a request to everybody and the kitchen
sink.
This belong on the cygwin ML, so please keep it here.
On Dec 12 10:40, Kavita Gore via Cygwin wrote:
> Hi all,
>
> I'm getting errno 27[EFBIG] file too large while opening catalogue with
> catopen() function in the cygwin-32bit version.
>
> [...]
> #define FILENAMETEMP.CAT
>
>buffer = catopen(FILENAME, 0);
> if (buffer != (nl_catd) - 1)
> {
> printf("File open successfully");
> }
> else
> {
> printf("errno: %d\n", errno);
> }
>
> While debugging using gdb.I've found that st.st_size is 0 and As per my
> understanding struct stat.st_size is declared as off_t, which is most
> probably signed, and resolves to long (signed by default).
Since you're running gdb anyway, why don't you *ask* gdb what type
off_t is?
(gdb) ptype off_t
type = long long
> So if SIZE_T_MAX does not fit into 2^31-1 (it most probably does not) it
> will appear as negative in the comparison.
No, under implicit type conversion rules, the comparison is well
defined. size_t is 32 bit on 32 bit systems, off_t is 64 bit. So the
comparison will convert __SIZE_MAX__ losslessly to long long. On 64 bit
systems, size_t is 64 bit, off_t is 64 bit. The comparison will be
performed unsigned, thus it will never be true.
$ cat > x.c <
#include
int
main (int argc, char **argv)
{
off_t o = strtoll (argv[1], NULL, 0);
if (o > __SIZE_MAX__)
puts ("too big");
}
EOF
$ gcc -g -o x x.c
On 32 bit:
$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
too big
On 64 bit:
$ ./x 0
$ ./x 1
$ ./x 0x
$ ./x 0x1
$ ./x 0x
$ ./x 0x7fff
$
> I'd like to know the reason why I'm getting this error and How it can be
> resolved as it is a blocker in my task.
You may have to debug this a bit further.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Strange behavior when executing programs
On Dec 12 11:21, Frank Redeker via Cygwin wrote: > $ pwd > /cygdrive/s/ado > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > Is there any way to restore the old behavior. Since with the new behavior my > tests no longer work. It's not easy. If we remove the new behaviour entirely, we break other scenarios which were broken in the old version. While it *seems* easy to fix your specific scenario, it will break again as soon as the substitution drive is used inside a native symlink. Virtual drive letters were always a problem and it doesn't get easier with Windows functions not allowing to specify whether one wants to follow symlinks or virt drives in inner path components or not. Let's consider this problem again, but I don't see a quick and easy solution. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Strange behavior when executing programs
On Dec 12 13:46, Frank Redeker via Cygwin wrote:
> Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen:
> > On Dec 12 11:21, Frank Redeker via Cygwin wrote:
> > > $ pwd
> > > /cygdrive/s/ado
> > >
> > > $ realpath /cygdrive/s/ado/msadox.dll
> > > /cygdrive/s/ado/msadox.dll
> > >
> > > $ realpath msadox.dll
> > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll
> > >
> > >
> > > Is there any way to restore the old behavior. Since with the new behavior
> > > my
> > > tests no longer work.
> >
> > It's not easy. If we remove the new behaviour entirely, we break
> > other scenarios which were broken in the old version. While it
> > *seems* easy to fix your specific scenario, it will break again
> > as soon as the substitution drive is used inside a native symlink.
> >
> > Virtual drive letters were always a problem and it doesn't get easier
> > with Windows functions not allowing to specify whether one wants to
> > follow symlinks or virt drives in inner path components or not.
> >
> > Let's consider this problem again, but I don't see a quick and easy
> > solution.
> >
> >
> > Corinna
> Hello Corinna, I am willing to create my own version, tailored to my needs.
Before you do that and decouple yourself from development, I'd suggest
to look for a workaround in your code, or to see if we can't patch this
behaviour in the upstream code.
> It would be nice if you could provide me with the commit that was used to
> implement the new behavior. (I guess the change is found inside the
> *git://sourceware.org/git/newlib-cygwin.git* repository)
Yes, but it's a group of patches trying to fix native symlink behaviour,
spread over a couple of iterations. If you're looking for an easy
workaround for your case, try this:
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index e7619270a269..131c7e88278f 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -3492,8 +3492,10 @@ restart:
{
/* Check if the final path is an UNC path and the incoming
path isn't. If so... */
- if (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE)
- && !RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE))
+ if (!RtlEqualUnicodePathPrefix (&upath, &ro_u_uncp, TRUE)
+ && (RtlEqualUnicodePathPrefix (&fpath, &ro_u_uncp, TRUE)
+ || towupper (upath.Buffer[4])
+!= towupper (fpath.Buffer[4])))
{
/* ...get the remote path, replace remote path
with drive letter, check again. */
However, a generic solution would be preferrable, and a local patch
to your scripts would be the better workaround for now.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 14:52, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > Let's consider this problem again, but I don't see a quick and easy > > solution. > > $ realpath /cygdrive/s/ado/msadox.dll > /cygdrive/s/ado/msadox.dll<== IMO the problem is actually here > > $ realpath msadox.dll > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > Both paths should start with /cygdrive/c, and then those would be identical > (and, hence, I suppose for the purposes of the OP). > > A substed drive is nothing BUT a symlink, should be treated no differently > than > /cygdrive/s -> /cygdrive/c/Program Files/Common Files/System I agree, and that was how I tried implementing it back when. The problem is that resolved paths may become longer than MAX_PATH. So people want to keep the paths with intact substituted drive prefix to run native commands from Cygwin. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 15:22, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > Sorry about the earlier typos > > > (and, hence, I suppose for the purposes of the OP). > > and, hence, I suppose, *would work* for the purposes of the OP. > > > Since realpath is supposed to resolve all symlinks, > > I meant by default (the -P behavior). If -s was asked, then the output would > be corect. Options are only available in realpath(1). As for under the hood, realpath(3) has no options so it can only return one of the alternatives. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > The problem is that resolved paths may become longer than MAX_PATH. > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, > symlinking is going to help work around that, > if the full path resolution was requested. > > BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't it > be enlarged? Cygwin handles up to 32K paths for a long time, just like the Windows kernel. It's the native tools and the Win32 ANSI file-API still using MAX_PATH as a path length restriction. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [EXTERNAL] Re: Strange behavior when executing programs
On Dec 12 16:42, Corinna Vinschen via Cygwin wrote: > On Dec 12 15:29, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote: > > > The problem is that resolved paths may become longer than MAX_PATH. > > > > Oh... But that'd be the same on any other OS that exceeds MAX_PATH, > > symlinking is going to help work around that, > > if the full path resolution was requested. > > > > BTW, about MAX_PATH -- was it Cygwin's or Windows'? If the former, can't > > it be enlarged? > > Cygwin handles up to 32K paths for a long time, just like the Windows > kernel. > > It's the native tools and the Win32 ANSI file-API still using MAX_PATH > as a path length restriction. Oh, and for kicks: Windows only allows MAX_PATH - 2 chars as the maximum path length of the current working directory. And that's a hard restriction you can't even workaround by using the UNICODE file-API. Windows 10 1607 lifts that restriction, but it's boarded up as an opt-in option. Therefore, as a developer, you can't rely on the user machines having this enabled, so you're kind of stuck. Cygwin's CWD doesn't have that restriction, it can be up to 32K long as well because it handles this internally. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Strange behavior when executing programs
On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > $ pwd > > > > /cygdrive/s/ado > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > $ realpath msadox.dll > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > [...] > However, a generic solution would be preferrable, and a local patch > to your scripts would be the better workaround for now. Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch trying to workaround the problem. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Strange behavior when executing programs
On Dec 13 13:54, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > > > $ pwd > > > > > > /cygdrive/s/ado > > > > > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > > > > > $ realpath msadox.dll > > > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > > > [...] > > > However, a generic solution would be preferrable, and a local patch > > > to your scripts would be the better workaround for now. > > > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > > trying to workaround the problem. > > > > > > Thanks, > > Corinna > Hello Corinna, > > I will try it out. Can you tell me where I can find the built cygwin.dll? Or > do I have to build the DLL myself. https://cygwin.com/faq.html#faq.api.testrels ;) Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Strange behavior when executing programs
On Dec 14 06:38, Frank Redeker via Cygwin wrote: > > > Am 12/13/2022 um 10:51 AM schrieb Corinna Vinschen: > > On Dec 12 14:09, Corinna Vinschen via Cygwin wrote: > > > On Dec 12 13:46, Frank Redeker via Cygwin wrote: > > > > Am 12/12/2022 um 1:12 PM schrieb Corinna Vinschen: > > > > > On Dec 12 11:21, Frank Redeker via Cygwin wrote: > > > > > > $ pwd > > > > > > /cygdrive/s/ado > > > > > > > > > > > > $ realpath /cygdrive/s/ado/msadox.dll > > > > > > /cygdrive/s/ado/msadox.dll > > > > > > > > > > > > $ realpath msadox.dll > > > > > > /cygdrive/c/Program Files/Common Files/System/ado/msadox.dll > > > > > > [...] > > > However, a generic solution would be preferrable, and a local patch > > > to your scripts would be the better workaround for now. > > > > Please test cygwin-3.5.0-0.30.g5ba5e09b9d39. It contains a patch > > trying to workaround the problem. > > > > > > Thanks, > > Corinna > Hello Corinna, > > thanks for your patch. It works as expected. > > $ uname -a > CYGWIN_NT-10.0-22000 W11-DEVELOP 3.5.0-0.30.g5ba5e09b9d39.x86_64 2022-12-12 > 21:37 UTC x86_64 Cygwin > > $ pwd > /cygdrive/s/ado > > $ realpath msadox.dll > /cygdrive/s/ado/msadox.dll > > $ sample.exe msadox.dll > [msadox.dll] -> [S:\ado\msadox.dll] Great, thanks for testing! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Fork issues with 3.4 in Docker only
On Dec 18 10:18, Christoph Reiter via Cygwin wrote: > After the upgrade to 3.4 (disclaimer: in MSYS2) I'm seeing, and getting > reports > of, various things failing in Docker only, for example: > > 1 [main] pacman 252 child_copy: dll data read copy failed, > 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 5096, Win32 error > 299 > 0 [main] pacman 251 dofork: child -1 - forked process 5096 died > unexpectedly, retry 0, exit code 0xC005, errno 11 > 0 [main] pacman 253 child_copy: dll data read copy failed, > 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 584, Win32 error > 299 > 67887 [main] pacman 251 dofork: child -1 - forked process 584 died > unexpectedly, retry 0, exit code 0xC005, errno 11 > 0 [main] pacman 254 child_copy: dll data read copy failed, > 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 2336, Win32 error > 299 > 124719 [main] pacman 251 dofork: child -1 - forked process 2336 died > unexpectedly, retry 0, exit code 0xC005, errno 11 > > Reverting > https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=943433b00cacdde0cb9507d0178770a2fb67bd71 > fixes things again. > > Note that this doesn't happen outside of Docker, I've built more than 100 > packages with 3.4 on different hosts without any issues, and the errors in > Docker are pretty consistent, so I'm guessing that something with ASLR behaves > differently under Docker(?) No idea what docker is doing differently, but you could try to switch off ASLR for the Cygwin DLL. Right now, starting with 3.4.0, it's supposed to be the only DLL using ASLR by default in the Cygwin distro, all other DLLs should still use fixed addresses. Try this: cp /bin/cygwin1.dll ~/docker-cygwin1.dll peflags -d0 ~/docker-cygwin1.dll Then copy that DLL over to /bin/cygwin1.dll in your docker image and try again. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Mailing list subscription problems
On Dec 19 12:50, David Standish via Cygwin wrote: > On 12/19/22, Kyle Marek via Cygwin wrote: > > (CC'd the public mailing list for visibility of problems that may be > > affecting others) > > > > Hello, > > > > Today I received an email from cygwin-boun...@cygwin.com with the > > subject line of "You have been unsubscribed from the Cygwin mailing > > list". I also just noticed that my Cygwin directory doesn't have any > > emails since the email identified by the following headers: > > [...] > > I've experienced the same problem. I reactivated my subscription a > couple times. > > More cygwin mail has been getting through to me that last few days. > Hopefully google has relaxed their filtering, Actually, Google hasn't relaxed their filtering, rather the DNS record of the cygwin.com domain was the culprit. It didn't have the required (by Google) DKIM/SFP records. This has been rectified last week, fortunately, so this shouldn't happen again. I re-enabled mail for all accounts having been disabled due to bounces. HTH, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: open /dev/null O_NOFOLLOW fails with ELOOP
Hi Glenn,
On Dec 21 06:15, gs-cygwin.com--- via Cygwin wrote:
> open /dev/null O_NOFOLLOW fails with ELOOP
>
> Windows 10, 64-bit cygwin
>
> Failed with my existing install, then I ran setup.exe, updated to
> latest, and my tests still failed.
>
> a.c
> ---
>
> #include
> #include
> #include
>
> int main (void)
> {
> int fd = open("/dev/null", O_RDWR | O_NOFOLLOW, 0);
> if (fd < 0)
> perror("open(/dev/null)");
> return fd;
> }
>
>
> $ gcc a.c ; ./a.exe
> open(/dev/null): Too many levels of symbolic links
>
> While troubleshooting this, there were times where it succeeded and then
> times where it failed, though it failed most of the time. It did not
> fail (or succeed) randomly, but seemingly in streaks.
>
> Trying to start lighttpd seems to run into this bug reliably,
> $ /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
> In the next release of lighttpd, I may end up omitting O_NOFOLLOW
> if __CYGWIN__ is defined.
Thanks for the report. I think I see what's going on, stay tuned.
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: open /dev/null O_NOFOLLOW fails with ELOOP
Hi Glenn,
On Dec 21 12:31, Corinna Vinschen via Cygwin wrote:
> On Dec 21 06:15, gs-cygwin.com--- via Cygwin wrote:
> > open /dev/null O_NOFOLLOW fails with ELOOP
> >
> > Windows 10, 64-bit cygwin
> >
> > Failed with my existing install, then I ran setup.exe, updated to
> > latest, and my tests still failed.
> >
> > a.c
> > ---
> >
> > #include
> > #include
> > #include
> >
> > int main (void)
> > {
> > int fd = open("/dev/null", O_RDWR | O_NOFOLLOW, 0);
> > if (fd < 0)
> > perror("open(/dev/null)");
> > return fd;
> > }
> >
> >
> > $ gcc a.c ; ./a.exe
> > open(/dev/null): Too many levels of symbolic links
> >
> > While troubleshooting this, there were times where it succeeded and then
> > times where it failed, though it failed most of the time. It did not
> > fail (or succeed) randomly, but seemingly in streaks.
> >
> > Trying to start lighttpd seems to run into this bug reliably,
> > $ /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
> > In the next release of lighttpd, I may end up omitting O_NOFOLLOW
> > if __CYGWIN__ is defined.
>
> Thanks for the report. I think I see what's going on, stay tuned.
I pushed a patch:
https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=09cb4cd2940f
Please try the latest test release cygwin-3.5.0-0.60.g09cb4cd2940f.
For installation, see https://cygwin.com/faq.html#faq.setup.testrels
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: open /dev/null O_NOFOLLOW fails with ELOOP
On Dec 21 14:32, gs-cygwin.com--- via Cygwin wrote: > On Wed, Dec 21, 2022 at 03:29:42PM +0100, Corinna Vinschen via Cygwin wrote: > > Hi Glenn, > > > > On Dec 21 12:31, Corinna Vinschen via Cygwin wrote: > > > On Dec 21 06:15, gs-cygwin.com--- via Cygwin wrote: > > > > open /dev/null O_NOFOLLOW fails with ELOOP > > > > [...] > > > > > > Thanks for the report. I think I see what's going on, stay tuned. > > > > I pushed a patch: > > https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=09cb4cd2940f > > > > Please try the latest test release cygwin-3.5.0-0.60.g09cb4cd2940f. > > For installation, see https://cygwin.com/faq.html#faq.setup.testrels > > > > > > Thanks, > > Corinna > > cygwin-3.5.0-0.60.g09cb4cd2940f works for my test case and for lighttpd. > I was unable to reproduce the problem after (somewhat limited) testing > with the test version. > > When I reverted back to 3.4.3-1, I was immediately able to reproduce the > issue with 3.4.3-1. > > Thank you! Happy Holidays! Thanks for testing and same to you! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: clang doesn't work from cygwin-3.4.0 (Re: clang-format and clang-check return 127 and no text)
On Jan 8 11:02, Jon Turney via Cygwin wrote: > On 08/01/2023 09:18, Csaba Raduly via Cygwin wrote: > > On Sun, 8 Jan 2023 at 09:11, ggl329 via Cygwin wrote: > > > > $ strace /usr/bin/clang --version > > strace.exe: error creating process C:\cygwin64\bin\clang, (error 5) > > This will usually avail you naught, as clang is a Cygwin symlink, and strace > as a pure Windows program doesn't understand those (which is what that error > is trying to tell you) > > $ strace $(realpath $(which clang)) > > shows the actual problem... > > --- > clang-8.exe - Entry Point Not Found > --- > The procedure entry point _alloca could not be located in the dynamic link > library C:\cygwin64\bin\cygLLVMSupport-8.dll. > --- This should be fixed in cygwin-3.5.0-0.72.g7886327fbf92 and, ultimately, a later 3.4.4 release. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 2 17:21, Takashi Yano via Cygwin wrote: > On Mon, 2 Jan 2023 14:38:03 +0900 > Takashi Yano wrote: > > On Mon, 2 Jan 2023 11:32:01 +0900 > > Takashi Yano wrote: > > > On Sat, 31 Dec 2022 13:01:29 -0700 > > > Brian Inglis wrote: > > > > was also getting the messages below locally and still on GitHub > > > > scallywag: > > > > > > > > cygcheck (6936) child_copy: cygheap read copy failed, > > > > > > > > ../curl/scallywag/1_x86_64 build.log:2022-12-26T00:39:35.6163236Z > > > > 0 > > > > [main] cygcheck (6936) child_copy: cygheap read copy failed, > > > > 0x0..0x80003B5F0, > > > > done 0, windows pid 6936, Win32 error 299 > > > > [...] > > I found this issue occurs after the commit 30add3e6b3e3: > > "Cygwin: exec: don't access cygheap before it's initialized" > > . > > > > Reverting this commit solves the issue. That would break strace again, but... > I'm not sure if this is the right thing, but the following > patch seems to fix the issue. This looks pretty good to me and it keeps strace working per the description in 30add3e6b3e3. Please push this to master and the 3.4 branch. Thanks! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
Hi Brian, On Dec 29 21:59, Brian Inglis via Cygwin wrote: > Hi folks, > > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps, and > even ls /proc/*/ when trying to cygport all check curl or look at the > process statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69... > > Had to revert to a Cygwin 3.4.0-344 test build from Dec 16 sources to build > and check curl etc. Given this looks like a regression, we'd need the exact version of the test DLL you were using. I. e., what SHA1 id did your HEAD have when you built this test DLL? Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 3 08:03, Takashi Yano via Cygwin wrote:
> On Mon, 2 Jan 2023 11:32:01 +0900
> Takashi Yano wrote:
> > On Thu, 29 Dec 2022 21:59:45 -0700
> > Brian Inglis wrote:
> > > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps,
> > > and
> > > even ls /proc/*/ when trying to cygport all check curl or look at the
> > > process
> > > statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69...
> > > [...]
> Do we need to guard here as well?
>
> case __SIGPENDING:
> {
> unsigned bit;
>
> *pack.mask = 0;
> tl_entry = cygheap->find_tls (pack.sigtls);
> while ((q = q->next))
> {
> /* Skip thread-specific signals for other threads. */
> if (q->sigtls && pack.sigtls != q->sigtls)
> continue;
> ---> if (pack.sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
> *pack.mask |= bit;
> }
> cygheap->unlock_tls (tl_entry);
> }
> break;
I'm not entirely clear what the right action is in terms of this sigtls
problem, but no, we don't need a guard in the __SIGPENDING branch.
__SIGPENDING is always called with a valid sigtls member in pack,
because __SIGPENDING is only called for a specific thread, either from
sigpending(2) or from fhandler_signalfd::poll(), which is called via
select(2).
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 2 11:32, Takashi Yano via Cygwin wrote:
> On Thu, 29 Dec 2022 21:59:45 -0700
> Brian Inglis wrote:
> > I got some hangs (deadlock?) between (parallel?) make jobs, top, procps,
> > and
> > even ls /proc/*/ when trying to cygport all check curl or look at the
> > process
> > statuses when builds hung under Cygwin 3.4.3 and 3.5.0-0.69...
> > [...]
> I have looked into this issue a bit, and found that
> q->sigtls becomes sometimes NULL and access violation
> occurs at the following code.
>
> winsup/cygwin/sigproc.cc: 1378
> if (q->sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
> {
> tl_entry = cygheap->find_tls (q->si.si_signo, issig_wait);
>
> I'm not sure why this happens, however it seems that
> the following patch fixes the issue.
>
> diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> index ce36c8be3..90eaa2a47 100644
> --- a/winsup/cygwin/sigproc.cc
> +++ b/winsup/cygwin/sigproc.cc
> @@ -1375,6 +1375,8 @@ wait_sig (VOID *)
> *pack.mask = 0;
> while ((q = q->next))
> {
> + if (q->sigtls == NULL)
> + continue;
> if (q->sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
> {
> tl_entry = cygheap->find_tls (q->si.si_signo, issig_wait);
>
> Corinna, could you please have a look?
If q->sigtls is NULL, the signal is nevertheless waiting for being
handled. It's just not directed at a specific thread. Beats me, why
this didn't occur in my testing. The process signal info should contain
the process-wide mask of pending signals as well, obviously, so the
following patch should do the right thing:
diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
index ce36c8be37fb..86e4e607ab7e 100644
--- a/winsup/cygwin/sigproc.cc
+++ b/winsup/cygwin/sigproc.cc
@@ -1375,7 +1375,8 @@ wait_sig (VOID *)
*pack.mask = 0;
while ((q = q->next))
{
- if (q->sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
+ _cygtls *sigtls = q->sigtls ?: _main_tls;
+ if (sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
{
tl_entry = cygheap->find_tls (q->si.si_signo, issig_wait);
if (tl_entry)
Can you confirm?
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 10 19:01, Takashi Yano via Cygwin wrote:
> On Mon, 9 Jan 2023 18:13:26 +0100
> Corinna Vinschen wrote:
> > If q->sigtls is NULL, the signal is nevertheless waiting for being
> > handled. It's just not directed at a specific thread. Beats me, why
> > this didn't occur in my testing. The process signal info should contain
> > the process-wide mask of pending signals as well, obviously, so the
> > following patch should do the right thing:
> >
> > diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> > index ce36c8be37fb..86e4e607ab7e 100644
> > --- a/winsup/cygwin/sigproc.cc
> > +++ b/winsup/cygwin/sigproc.cc
> > @@ -1375,7 +1375,8 @@ wait_sig (VOID *)
> > *pack.mask = 0;
> > while ((q = q->next))
> > {
> > - if (q->sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
> > + _cygtls *sigtls = q->sigtls ?: _main_tls;
> > + if (sigtls->sigmask & (bit = SIGTOMASK (q->si.si_signo)))
> > {
> > tl_entry = cygheap->find_tls (q->si.si_signo, issig_wait);
> > if (tl_entry)
> >
> > Can you confirm?
>
> I confirmed that your patch fixes the issue.
>
> This issue can be easily reproduced in my environment by:
> 1) Open two mintty windows.
> 2) Run "while true; do procps; done" in one mintty.
> 3) Build cygwin1.dll in another window.
> Build hangs in a short time and response of procps slows down.
Great. I pushed the patch. The next test relaese
cygwin-3.5.0-0.76.g7c14e5a10add contains this patch.
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: MS Windows 8.1 EoL today
On Jan 10 14:42, Brian Inglis via Cygwin wrote: > Hi folks, > > As MS Windows 8.1 has gone EoL today: > > https://learn.microsoft.com/en-us/lifecycle/products/windows-81?source=recommendations > > with Chrome, Edge, and other product support also ending this month, is > Cygwin 3.4.3 also the last release to support that and equivalent server > releases, and should that be clarified on the web pages and announcements. There are no plans to drop 8.1 support any time soon, and all 3.4.x versions will continue to run on Windows 7 and later, as already outlined in basically all cygwin package announcements since Cygwin 3.3.0: https://cygwin.com/pipermail/cygwin-announce/2021-October/010268.html [...] https://cygwin.com/pipermail/cygwin-announce/2022-December/010831.html Only the 3.4.3 release announcement is missing this info accidentally. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: clang doesn't work from cygwin-3.4.0 (Re: clang-format and clang-check return 127 and no text)
On Jan 11 00:35, ggl329 via Cygwin wrote: > On 2023/01/09 22:05, Corinna Vinschen via Cygwin wrote: > > On Jan 8 11:02, Jon Turney via Cygwin wrote: > > > > > > $ strace $(realpath $(which clang)) > > > > > > shows the actual problem... > > > > > > --- > > > clang-8.exe - Entry Point Not Found > > > --- > > > The procedure entry point _alloca could not be located in the dynamic link > > > library C:\cygwin64\bin\cygLLVMSupport-8.dll. > > > --- > > > > This should be fixed in cygwin-3.5.0-0.72.g7886327fbf92 and, > > ultimately, a later 3.4.4 release. > > I confirmed that clang exits successfully > in cygwin-3.5.0-0.79.g3b7df69aaa57 environment. > Thanks. Thanks for testing! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cpio 2.13-13
The following packages have been uploaded to the Cygwin distribution: * cpio-2.13-13 GNU cpio copies files into or out of a cpio or tar archive. Archives are files which contain a collection of other files plus information about them, such as their file name, owner, timestamps, and access permissions. The archive can be another file on the disk, a magnetic tape, or a pipe. GNU cpio supports the following archive formats: binary, old ASCII, new ASCII, crc, HPUX binary, HPUX old ASCII, old tar and POSIX.1 tar. By default, cpio creates binary format archives, so that they are compatible with older cpio programs. When it is extracting files from archives, cpio automatically recognizes which kind of archive it is reading and can read archives created on machines with a different byte-order. Install cpio if you need a program to manage file archives. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] rebase 4.6.2-2
The following packages have been uploaded to the Cygwin distribution: * rebase-4.6.2-2 This package contains the Cygwin rebase utilities. Use rebase for specific DLLs or rebaseall for all DLLs installed by Cygwin's setup.exe. This is a minor bug fix release, fixing a confusing warning in peflags. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
newlib-cygwin.git repository: Switching "master" to "main"
Hey folks, In the light of recent discussions, and following other projects already having done this step, we changed the name of the "master" branch in the newlib-cygwin.git upstream repository to "main". If you fetched from upstream in the last two days, you might already have noticed that an "origin/main" branch suddenly showed up, but your "master" branch still worked as before. The reason is that we also added a symbolic reference upstream, so that "origin/master" points to "origin/main". Both "branches" are now constantly kept in sync upstream. Therefore, you can continue your work on "master" without disruption, if you prefer to do so. However, on the client side, the "master" and "main" branches are treated as two distinct branches. If you work on your local "main" clone and commit a patch, it's not keeping your local "master" branch in sync. After pushing your change upstream, though, the upstream idea of "main" and "master" is, again, the same. After fetching from upstream, the patch will show up in both tracking branches, "origin/main" as well as "origin/master", so pulling on both local branches will show the same tree. Having said that. Ideally you only use one of the branches locally to avoid any confusion: - If you prefer to work in "master", just continue to do so and don't create a local "main" branch tracking "origin/main". - If you prefer to work in "main", checkout "origin/main" as "main" and delete your local "master" branch. Have fun, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: newlib-cygwin.git repository: Switching "master" to "main"
On Jan 13 12:55, Corinna Vinschen wrote: > Hey folks, > > In the light of recent discussions, and following other projects already > having done this step, we changed the name of the "master" branch in > the newlib-cygwin.git upstream repository to "main". > > If you fetched from upstream in the last two days, you might already > have noticed that an "origin/main" branch suddenly showed up, but your > "master" branch still worked as before. > > The reason is that we also added a symbolic reference upstream, so that > "origin/master" points to "origin/main". Both "branches" are now > constantly kept in sync upstream. > > Therefore, you can continue your work on "master" without disruption, > if you prefer to do so. > > However, on the client side, the "master" and "main" branches are > treated as two distinct branches. If you work on your local "main" > clone and commit a patch, it's not keeping your local "master" branch in > sync. After pushing your change upstream, though, the upstream idea of > "main" and "master" is, again, the same. After fetching from upstream, > the patch will show up in both tracking branches, "origin/main" as well > as "origin/master", so pulling on both local branches will show the same > tree. > > Having said that. Ideally you only use one of the branches locally > to avoid any confusion: > > - If you prefer to work in "master", just continue to do so and don't > create a local "main" branch tracking "origin/main". > > - If you prefer to work in "main", checkout "origin/main" as "main" and > delete your local "master" branch. Oh, and, btw., if you clone the newlib-cygwin.git repo anew, you will by default get a local "main" branch tracking "origin/main". Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: newlib-cygwin.git repository: Switching "master" to "main"
On Jan 13 14:20, Sam Edge via Cygwin wrote: > On 13/01/2023 11:55, Corinna Vinschen via Cygwin wrote: > > Hey folks, > > > > In the light of recent discussions, and following other projects already > > having done this step, we changed the name of the "master" branch in > > the newlib-cygwin.git upstream repository to "main". > > > > If you fetched from upstream in the last two days, you might already > > have noticed that an "origin/main" branch suddenly showed up, but your > > "master" branch still worked as before. > > > > The reason is that we also added a symbolic reference upstream, so that > > "origin/master" points to "origin/main". Both "branches" are now > > constantly kept in sync upstream. > > > > Therefore, you can continue your work on "master" without disruption, > > if you prefer to do so. > > > > However, on the client side, the "master" and "main" branches are > > treated as two distinct branches. If you work on your local "main" > > clone and commit a patch, it's not keeping your local "master" branch in > > sync. After pushing your change upstream, though, the upstream idea of > > "main" and "master" is, again, the same. After fetching from upstream, > > the patch will show up in both tracking branches, "origin/main" as well > > as "origin/master", so pulling on both local branches will show the same > > tree. > > > > Having said that. Ideally you only use one of the branches locally > > to avoid any confusion: > > > > - If you prefer to work in "master", just continue to do so and don't > > create a local "main" branch tracking "origin/main". > > > > - If you prefer to work in "main", checkout "origin/main" as "main" and > > delete your local "master" branch. > > > > > > Have fun, > > Corinna > > > > > > While I can understand sensitivity over the word 'slave' this is taking > things > too far in my opinion. I just conducted a quick poll of my Afro-Caribbean & > other non-Caucasian workmates who all express the same sentiment. > [...] > Well, it's a fait accompli on the Cygwin repos. That's why we chose the symbolic ref solution. You can use both in future, whichever you like more. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] patch 2.7.6-17
The following packages have been uploaded to the Cygwin distribution: * patch-2.7.6-17 The patch program applies diff files to originals. The diff command is used to compare an original to a changed file. Diff lists the changes made to the file. A person who has the original file can then use the patch command with the diff file to add the changes to their original file (patching the file). Patch should be installed because it is a common way of upgrading applications. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] file 5.44-1
The following packages have been uploaded to the Cygwin distribution: * file-5.44-1 * file-devel-5.44-1 * python3-magic-5.44-1 The file command is used to identify a particular file according to the type of data contained by the file. File can identify many different file types, including ELF binaries, system libraries, RPM packages, and different graphics formats. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] attr 2.5.1-1.20.g0981a7bfe487
The following packages have been uploaded to the Cygwin distribution: * attr-2.5.1-1.20.g0981a7bfe487 * libattr-devel-2.5.1-1.20.g0981a7bfe487 * libattr1-2.5.1-1.20.g0981a7bfe487 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: vmstat yields error 'Unable to create system stat structure' on W11x64
On Jan 15 22:04, System Administrator via Cygwin wrote: > Hello, > > I am trying to migrate my framework to Windows 11 running Cygwin. > When executing vmstat it returns the following error: > > "Unable to create system stat structure” > > Using the very same packages (install files) on Windows 10, produces the > proper vmstat results (i.e. no error). > I’ve tried W11 pro and Enterprise - same difference (none.) Windows 11 is > running in a VMware VM. W11 is the December version wit the latest updates > (as of today). > The working W10 is running on the same physical hardware, using the same > version of VMware, also in a VM. > Cygwin is the latest version 3.4.3, with the latest props-ng package (4.0.2-1) > > Any help (or at least hint) is greatly appreciated. I don't think this has anything to do with Windows10 or 11, but with the version of procps-ng you're running. I tried vmstat from procps-ng-4.0.2-1 on both, W10 and W11, and I got the above error in both cases. I switched back to procps-ng-3.3.17-1 and vmstat worked fine on both, W10 and W11. I ran vmstat from procps-ng-4.0.2-1 under GDB and found that this vmstat tries to dynamically load libnuma.so or libnuma.1.so, both of which are naturally not available on Cygwin. So I guess vmstat from procps-ng-4.x still needs another patch. Achim? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 16 18:02, Takashi Yano via Cygwin wrote: > Hi Corinna, > > On Mon, 9 Jan 2023 14:20:56 +0100 > Corinna Vinschen wrote: > > On Jan 2 17:21, Takashi Yano via Cygwin wrote: > > > On Mon, 2 Jan 2023 14:38:03 +0900 > > > Takashi Yano wrote: > > > > On Mon, 2 Jan 2023 11:32:01 +0900 > > > > Takashi Yano wrote: > > > > > On Sat, 31 Dec 2022 13:01:29 -0700 > > > > > Brian Inglis wrote: > > > > > > was also getting the messages below locally and still on GitHub > > > > > > scallywag: > > > > > > > > > > > > cygcheck (6936) child_copy: cygheap read copy failed, > > > > > > > > > > > > ../curl/scallywag/1_x86_64 build.log:2022-12-26T00:39:35.6163236Z > > > > > > 0 > > > > > > [main] cygcheck (6936) child_copy: cygheap read copy failed, > > > > > > 0x0..0x80003B5F0, > > > > > > done 0, windows pid 6936, Win32 error 299 > > > > > > [...] > > > > I found this issue occurs after the commit 30add3e6b3e3: > > > > "Cygwin: exec: don't access cygheap before it's initialized" > > > > . > > > > > > > > Reverting this commit solves the issue. > > > > That would break strace again, but... > > > > > I'm not sure if this is the right thing, but the following > > > patch seems to fix the issue. > > > > This looks pretty good to me and it keeps strace working per the > > description in 30add3e6b3e3. Please push this to master and the > > 3.4 branch. > > I noticed that the following error occurs even with this patch. > If you run: > while true; do cygcheck -cd cygwin > /dev/null; done > for one day or so, you will find the issue can be reproduced. > > Both cygwin-3_4-branch and main (master) branch have this issue, > while cygwin 3.3.6 does not. > > $ while true; do cygcheck -cd cygwin > /dev/null; done > 0 [main] cygcheck (15244) C:\cygwin64\bin\cygcheck.exe: *** fatal error > - > MapViewOfFileEx 'shared.5'(0x138), Win32 error 487. Terminating. >3540 [main] cygcheck (15244) cygwin_exception::open_stackdumpfile: Dumping > st > ack trace to cygcheck.exe.stackdump > 0 [main] cygcheck (10844) C:\cygwin64\bin\cygcheck.exe: *** fatal error > - > MapViewOfFileEx 'cygpid.51742'(0x148), Win32 error 487. Terminating. > 0 [main] cygcheck (1976) C:\cygwin64\bin\cygcheck.exe: *** fatal error > - M [...] > Errors seem to be three types: (null), cygpid.xxx and shared.5. > I'm not sure what is happening and why at all, however, this > did not seem to happen before the commit 30add3e6b3e3. I'll try to reproduce this issue. But the weird thing is certainly this: The affected shared mem regions are apparently not the cygheap. Rather, they are the "shared" and "cygpid" shared mem regions, which should not at all collide with the cygheap. I guess we need more debug output in the api_fatal call inside open_shared... Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: vmstat yields error 'Unable to create system stat structure' on W11x64
On Jan 16 11:19, Corinna Vinschen via Cygwin wrote: > On Jan 15 22:04, System Administrator via Cygwin wrote: > > Hello, > > > > I am trying to migrate my framework to Windows 11 running Cygwin. > > When executing vmstat it returns the following error: > > > > "Unable to create system stat structure” > > [...] > I don't think this has anything to do with Windows10 or 11, but with the > version of procps-ng you're running. > > I tried vmstat from procps-ng-4.0.2-1 on both, W10 and W11, and I got > the above error in both cases. > > I switched back to procps-ng-3.3.17-1 and vmstat worked fine on both, > W10 and W11. > > I ran vmstat from procps-ng-4.0.2-1 under GDB and found that this > vmstat tries to dynamically load libnuma.so or libnuma.1.so, both > of which are naturally not available on Cygwin. So I guess vmstat > from procps-ng-4.x still needs another patch. While that's obviously wrong, it's not the problem. It turns out that vmstat from procps-ng 4.0.2 stumbles over the fact, that /proc/cpuinfo only prints the following fields if the CPU is a multi core CPU: "physical id" "siblings", "core id" "cpu cores" "apicid" "initial apicid" On Linux the output of those fields only depends on the configuration of the kernel. If it has been built with CONFIG_SMP, these fields are part of the /proc/cpuinfo output. On Cygwin, the output of these fields actually depends on the fact if the HTT CPU flag is set or not. If not, it's not a multi core CPU and the aforementioned fields are omitted. I could reproduce this issue by changing the CPU topology in my QEMU/KVM Windows 10 machine. The default topology was 4 CPUs with 1 core and 1 thread each. I changed that to 2 CPUs with 2 cores and 1 thread each. After restarting the W10 machine, vmstat from procps-ng 4.0.2 started working as desired. So we can fix this issue by tweaking Cygwin instead. I guess this will be fodder for the upcoming 3.4.4 release. I'll also provide a test release in a bit, stay tuned. Achim, I still wonder if vmstat shouldn't also work on Linux if the kernel hasn't been built with CONFIG_SMP. Does the vmstat code fail to take that into account? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
Hi Takashi,
On Jan 16 23:45, Takashi Yano via Cygwin wrote:
> On Mon, 16 Jan 2023 11:23:54 +0100
> Corinna Vinschen wrote:
> > On Jan 16 18:02, Takashi Yano via Cygwin wrote:
> > [...]
> > > Errors seem to be three types: (null), cygpid.xxx and shared.5.
> > > I'm not sure what is happening and why at all, however, this
> > > did not seem to happen before the commit 30add3e6b3e3.
> >
> > I'll try to reproduce this issue. But the weird thing is certainly
> > this: The affected shared mem regions are apparently not the cygheap.
> > Rather, they are the "shared" and "cygpid" shared mem regions, which
> > should not at all collide with the cygheap. I guess we need more
> > debug output in the api_fatal call inside open_shared...
>
> I am now trying the test case with reverting the commit 60675f1a7eb2
> "Cygwin: decouple shared mem regions from Cygwin DLL", and the issue
> does not happen for several hours so far. I guess this most likely
> is the direct cause of the problem.
Actually, I' running your testcase on two machines in parallel now for
quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e.
diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc
index 893b20d289b4..6d6d2940b6d4 100644
--- a/winsup/cygwin/mm/shared.cc
+++ b/winsup/cygwin/mm/shared.cc
@@ -140,7 +140,11 @@ open_shared (const WCHAR *name, int n, HANDLE& shared_h,
DWORD size,
if (*m == SH_JUSTCREATE || *m == SH_JUSTOPEN)
addr = NULL;
else
-addr = (void *) region_address[*m];
+{
+ addr = (void *) region_address[*m];
+ VirtualFree (addr, 0, MEM_RELEASE);
+}
+
WCHAR map_buf[MAX_PATH];
WCHAR *mapname = NULL;
So far (and knocking on wood madly while writing this) the mapping
problem didn't show up once. Maybe you'd like to try the same?
Btw., I pinged you on IRC already 3 hours ago...
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: vmstat yields error 'Unable to create system stat structure' on W11x64
On Jan 16 14:08, Corinna Vinschen via Cygwin wrote: > On Jan 16 11:19, Corinna Vinschen via Cygwin wrote: > > On Jan 15 22:04, System Administrator via Cygwin wrote: > > > Hello, > > > > > > I am trying to migrate my framework to Windows 11 running Cygwin. > > > When executing vmstat it returns the following error: > > > > > > "Unable to create system stat structure” > > > [...] > While that's obviously wrong, it's not the problem. It turns out that > vmstat from procps-ng 4.0.2 stumbles over the fact, that /proc/cpuinfo > only prints the following fields if the CPU is a multi core CPU: ...in short, the topology info. > On Linux the output of those fields only depends on the configuration > of the kernel. If it has been built with CONFIG_SMP, these fields are > part of the /proc/cpuinfo output. > > On Cygwin, the output of these fields actually depends on the fact if > the HTT CPU flag is set or not. If not, it's not a multi core CPU and > the aforementioned fields are omitted. > > I could reproduce this issue by changing the CPU topology in my QEMU/KVM > Windows 10 machine. The default topology was 4 CPUs with 1 core and 1 > thread each. I changed that to 2 CPUs with 2 cores and 1 thread each. > After restarting the W10 machine, vmstat from procps-ng 4.0.2 started > working as desired. > > So we can fix this issue by tweaking Cygwin instead. I guess this will > be fodder for the upcoming 3.4.4 release. > > I'll also provide a test release in a bit, stay tuned. For testing, please check out the Cygwin test release 3.5.0-0.110.g75c375e86df3 via the setup tool and report back. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
Hi Takashi,
On Jan 16 16:18, Corinna Vinschen via Cygwin wrote:
> Actually, I' running your testcase on two machines in parallel now for
> quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e.
>
> diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc
> index 893b20d289b4..6d6d2940b6d4 100644
> --- a/winsup/cygwin/mm/shared.cc
> +++ b/winsup/cygwin/mm/shared.cc
> @@ -140,7 +140,11 @@ open_shared (const WCHAR *name, int n, HANDLE& shared_h,
> DWORD size,
>if (*m == SH_JUSTCREATE || *m == SH_JUSTOPEN)
> addr = NULL;
>else
> -addr = (void *) region_address[*m];
> +{
> + addr = (void *) region_address[*m];
> + VirtualFree (addr, 0, MEM_RELEASE);
> +}
> +
>
>WCHAR map_buf[MAX_PATH];
>WCHAR *mapname = NULL;
>
> So far (and knocking on wood madly while writing this) the mapping
> problem didn't show up once. Maybe you'd like to try the same?
Never mind, I encountered another error. After a bit more debugging
I think I understand the problem now, and I'm just in the process of
reworking open_shared. This may take a day or two. Stay tuned.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
Hi Takashi,
On Jan 16 22:42, Corinna Vinschen via Cygwin wrote:
> On Jan 16 16:18, Corinna Vinschen via Cygwin wrote:
> > Actually, I' running your testcase on two machines in parallel now for
> > quite some time, which only one hunk of 60675f1a7eb2 reverted, i.e.
> >
> > diff --git a/winsup/cygwin/mm/shared.cc b/winsup/cygwin/mm/shared.cc
> > index 893b20d289b4..6d6d2940b6d4 100644
> > --- a/winsup/cygwin/mm/shared.cc
> > +++ b/winsup/cygwin/mm/shared.cc
> > @@ -140,7 +140,11 @@ open_shared (const WCHAR *name, int n, HANDLE&
> > shared_h, DWORD size,
> >if (*m == SH_JUSTCREATE || *m == SH_JUSTOPEN)
> > addr = NULL;
> >else
> > -addr = (void *) region_address[*m];
> > +{
> > + addr = (void *) region_address[*m];
> > + VirtualFree (addr, 0, MEM_RELEASE);
> > +}
> > +
> >
> >WCHAR map_buf[MAX_PATH];
> >WCHAR *mapname = NULL;
> >
> > So far (and knocking on wood madly while writing this) the mapping
> > problem didn't show up once. Maybe you'd like to try the same?
>
> Never mind, I encountered another error. After a bit more debugging
> I think I understand the problem now, and I'm just in the process of
> reworking open_shared. This may take a day or two. Stay tuned.
I pushed some patches to fix this issue. Excessive debugging indicated
that the reason cygcheck fails in this way is:
- It's a non-Cygwin process which
- is built with high-entropy ASLR and
- tries to load the Cygwin DLL dynamically and
- therefore suffers from the fact that recent Cygwin code doesn't
expect that certain memory regions are used by Windows itself.
Which they are, due to the high-entropy stuff.
The patches are supposed to make the code less rigid in terms of the
addresses of certain memory regions, as well as dropping the
high-entropy VA flag from builds of strace and cygcheck, both of which
are loading the Cygwin DLL dynamically as part of their job.
The test release 3.5.0-0.116.g8d318bf142f7 contains the patches, for
everybody to try.
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
Hi Takashi, On Jan 18 18:16, Takashi Yano via Cygwin wrote: > > On Jan 16 22:42, Corinna Vinschen via Cygwin wrote: > > I pushed some patches to fix this issue. Excessive debugging indicated > > that the reason cygcheck fails in this way is: > > > > - It's a non-Cygwin process which > > > > - is built with high-entropy ASLR and > > > > - tries to load the Cygwin DLL dynamically and > > > > - therefore suffers from the fact that recent Cygwin code doesn't > > expect that certain memory regions are used by Windows itself. > > Which they are, due to the high-entropy stuff. > > > > The patches are supposed to make the code less rigid in terms of the > > addresses of certain memory regions, as well as dropping the > > high-entropy VA flag from builds of strace and cygcheck, both of which > > are loading the Cygwin DLL dynamically as part of their job. > > > > The test release 3.5.0-0.116.g8d318bf142f7 contains the patches, for > > everybody to try. > > Thank you very much for working on this problem. It seems that > it was unexpectedly large-scale modification. > > I confirmed that the problem has been fixed with these patches. > The test case has been running for 11 hours but the problem does > not happen so far. Great. I tested this yesterday with 7 runs on two machines in parallel while building Cygwin continuously in another Window, and cygcheck still with high-entropy-VA enabled. And one of the machines continued to run the cygcheck loops over night and were still in good shape this morning :) I guess we should release 3.4.4 pretty soon now. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 3.4.3 and 3.5.0... hangs in make, top, procps, ls /proc/PID/...
On Jan 19 09:31, Brian Inglis via Cygwin wrote: > On 2023-01-18 02:42, Corinna Vinschen via Cygwin wrote: > > I tested this yesterday with 7 runs on two machines in parallel while > > building Cygwin continuously in another Window, and cygcheck still with > > high-entropy-VA enabled. And one of the machines continued to run the > > cygcheck loops over night and were still in good shape this morning :) > > > > I guess we should release 3.4.4 pretty soon now. > > I installed and tested 3.5.0-0.122.g3c2ac163da88.x86_64 instead, as that was > the autoselected test version. > > When cygcheck -hrsv was run as usual in local postinstall script > zp_z2_l_cygcheck-hrsv.dash gave error msg box can't find zlib1.dll - but > it's there: > > $ ls -glo /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll > -rwxr-xr-x 1 117267 Oct 15 12:14 > /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll > > Under X/mintty/bash cygcheck will not even start - says so in error msg box > with code 0xc07b! Drat. I pushed a patch. This is fixed in 3.5.0-0.124.g1d4110e347ad.x86_64 and the upcoming 3.4.5 (had to skip 3.4.4, don't ask...) Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.5-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.5-1 * cygwin-devel-3.4.5-1 * cygwin-doc-3.4.5-1 The 3.4.4 release had to be skipped for technical reasons. Bug Fixes - - Fix an uninitialized variable having weird side-effects in path handling. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252734.html - Fix hang-up of less on quit which occurs when it is started from non-cygwin shell and window is resized. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252737.html - Reinstantiate exporting _alloca. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252797.html - Avoid hangs when reading /proc//status. Addresses: https://cygwin.com/pipermail/cygwin/2022-December/252756.html - Fix vmstat(1) printing an error message on single core CPUs. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252857.html - Fix potential process termination during process initialization. Most easily reproducible is the case of non-Cygwin processes running with high-entropy VA enabled and loading the Cygwin DLL dynamically. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252765.html https://cygwin.com/pipermail/cygwin/2023-January/252865.html - Fix a build problem breaking cygcheck and strace. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252894.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Feature request: sudo
On Jan 19 20:17, Jochen Wiedmann via Cygwin wrote: > Hi, > > as someone who is quite used to typing > > sudo do something > > I would really like to do the same in my CygWin bash.In my opinion, > this could be implemented > relatively simply, and straightforward as follows: > > - Accept an array of strings with the command, that is being > executed with administrator > privileges. > - Use the standard Windows API to execute some functionality with > admin privileges. > In the current case, that functionality would be a simple exec > with the above command line. Assuming you already are running an administrative account and you just want to elevate a process, rather than actually switching the user context to, say, "Administrator". - The underlying Win32 system calls implementing fork/execve, i.e. CreateProcess and CreateProcessAsUser, don't allow to start an elevated process from a non-elevated process, unless you already have access to your elevated token. While you can actually access that token, this token is not suitable for CreateProcessAsUser, unless you access it with TCB privileges... which only an already elevated process has. - Windows doesn't provide SUID/SGID bits. They are just faked in Cygwin using some bits in a NULL SID. Thus, a sudo tool with SUID bit set is not workable on Windows, unless you control running an executable from an already privileged process which creates the user token. This could be done by cygserver, but nobody implemented that yet. https://cygwin.com/acronyms/#SHTDI Having said that, you can kind of do it yourself: - Install and run Cygwin's sshd as a service. - Create a public key pair. - alias sudo='ssh localhost' Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error: child_copy: cygheap read copy failed.
On Jan 20 12:56, Takashi Yano via Cygwin wrote: > Hi Corinna, > > I am now working on porting ffmpeg for cygwin, and noticed that > the following error sometimes happens. > > $ while true; do ffplay 2>&1 |grep cygheap; done > 0 [main] ffplay (10172) child_copy: cygheap read copy failed, > 0x0..0x800028FB8, done 0, windows pid 10172, Win32 error 299 > > This seems to happen after the commit: > > commit 2f9b8ff00cce0d0ceeb1091b6b9aecae914ddb89 > Author: Corinna Vinschen > Date: Wed Oct 26 21:16:35 2022 +0200 > > Cygwin: decouple cygheap from Cygwin DLL > [...] > I looked into this problem a bit and found that VirtualAlloc() > for MEM_RESERVE of cygheap area in cygheap_fixup_in_child() > failed with ERROR_INVALID_ADDRESS. It seems that the address > range is already occupied for some reason. You should try to find out what that is. > > I also noticed that the following patch seems to resolve the issue. > > diff --git a/winsup/cygwin/local_includes/memory_layout.h > b/winsup/cygwin/local_includes/memory_layout.h > index a3a0cae70..67164cfaf 100644 > --- a/winsup/cygwin/local_includes/memory_layout.h > +++ b/winsup/cygwin/local_includes/memory_layout.h > @@ -44,15 +44,15 @@ details. */ > > /* That's where the cygheap is located. CYGHEAP_STORAGE_INITIAL defines the > end of the initially committed heap area. */ > -#define CYGHEAP_STORAGE_LOW 0x8UL > -#define CYGHEAP_STORAGE_INITIAL 0x80030UL > -#define CYGHEAP_STORAGE_HIGH 0xaUL > +#define CYGHEAP_STORAGE_LOW 0x700UL > +#define CYGHEAP_STORAGE_INITIAL 0x730UL > +#define CYGHEAP_STORAGE_HIGH 0x702UL > > /* This is where the user heap starts. There's no defined end address. > The user heap pontentially grows into the mmap arena. However, > the user heap grows upwards and the mmap arena grows downwards, > so there's not much chance to meet unluckily. */ > -#define USERHEAP_START 0xaUL > +#define USERHEAP_START 0x8UL That doesn't make sense. So we now have the user heap in place of the cygheap, and that works? So why should anything occuping the 0x8 - 0xa area if the cygheap needs it, suddenly not occupy it when the user heap needs it? Of course, this could be a result of the user heap not being reserved in full size like the cygheap is. The fact that it works with your patch above points to an incidental success, with the user heap keeping most of the area from 0x8 - 0xa free. It would then fail only later, if the application tries to raise the user heap beyond a certain size. Right now this looks like a very special case. I don't know what I should do from my side. Please add debug output and/or use vmmap from sysinternals to find out what's actually occupying the area from 0x8 - 0xa and where exactly. Also, your ffplay executable isn't high-entropy-VA enabled, by any chance? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error: child_copy: cygheap read copy failed.
On Jan 20 21:18, Takashi Yano via Cygwin wrote:
> On Fri, 20 Jan 2023 12:30:29 +0100
> Corinna Vinschen wrote:
> > Also, your ffplay executable isn't high-entropy-VA enabled, by any
> > chance?
>
> I'm sorry, but the high-entropy-va is ebabled.
>
> $ peflags -v /usr/bin/ff{mpeg,probe,play}
> /usr/bin/ffmpeg:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> /usr/bin/ffprobe:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> /usr/bin/ffplay:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
>
> peflags -e0 /usr/bin/ff{mpeg,probe,play} solves the issue.
> Thansk!
I'm glad to read that, actually!
> Shoud I remove dynamicbase flag as well?
I did a lot of local testing with ASLR locally, and it's fine for DLLs,
but not so much for the application executable itself.
You can keep dynamicbase for testing, but currently it's not advised
to do so, and you should definitely remove it for distro executables.
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error: child_copy: cygheap read copy failed.
On Jan 20 21:18, Takashi Yano via Cygwin wrote:
> On Fri, 20 Jan 2023 12:30:29 +0100
> Corinna Vinschen wrote:
> > Also, your ffplay executable isn't high-entropy-VA enabled, by any
> > chance?
>
> I'm sorry, but the high-entropy-va is ebabled.
>
> $ peflags -v /usr/bin/ff{mpeg,probe,play}
> /usr/bin/ffmpeg:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> /usr/bin/ffprobe:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> /usr/bin/ffplay:
> coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
Btw., how did this happen? The native Cygwin compiler/linker combo
usually doesn't set the dynamicbase and high-entropy-VA flags by
default...
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Error: child_copy: cygheap read copy failed.
On Jan 20 22:30, Takashi Yano via Cygwin wrote:
> On Fri, 20 Jan 2023 13:26:20 +0100
> Corinna Vinschen wrote:
> > On Jan 20 21:18, Takashi Yano via Cygwin wrote:
> > > On Fri, 20 Jan 2023 12:30:29 +0100
> > > Corinna Vinschen wrote:
> > > > Also, your ffplay executable isn't high-entropy-VA enabled, by any
> > > > chance?
> > >
> > > I'm sorry, but the high-entropy-va is ebabled.
> > >
> > > $ peflags -v /usr/bin/ff{mpeg,probe,play}
> > > /usr/bin/ffmpeg:
> > > coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> > > pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> > > /usr/bin/ffprobe:
> > > coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> > > pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> > > /usr/bin/ffplay:
> > > coff(0x022e[+executable_image,+line_nums_stripped,+local_syms_stripped,+bigaddr,+sepdbg])
> > > pe(0x8160[+high-entropy-va,+dynamicbase,+nxcompat,+tsaware])
> >
> > Btw., how did this happen? The native Cygwin compiler/linker combo
> > usually doesn't set the dynamicbase and high-entropy-VA flags by
> > default...
>
> Perhaps this is because configure of ffmpeg explicitly
> has the following lines:
>
> check_ldflags -Wl,--nxcompat,--dynamicbase
> check_ldflags -Wl,--high-entropy-va # binutils 2.25
Oh, ok. The configurey should only do that on native Windows builds.
> Removing these lines makes ff{mpeg,probe,play} disable
> both high-entropy-va and dynamicbase flags.
Great!
Thanks,
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] psmisc 23.4-4
The following packages have been uploaded to the Cygwin distribution: * psmisc-23.4-4 The psmisc package contains utilities for managing processes on your system: pstree, killall, fuser and pslog. The pstree command displays a tree structure of all of the running processes on your system. The killall command sends a specified signal (SIGTERM if nothing is specified) to processes identified by name. The fuser command identifies the PIDs of processes that are using specified files or filesystems. The pslog command shows the path of log files owned by a given process. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libedit 20221030-1
The following packages have been uploaded to the Cygwin distribution: * libedit-20221030-1 * libedit-devel-20221030-1 * libedit0-20221030-1 Libedit is an autotool- and libtoolized port of the NetBSD Editline library. It provides generic line editing, history, and tokenization functions, similar to those found in GNU Readline. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libcbor 0.9.0-4
The following packages have been uploaded to the Cygwin distribution: * libcbor-0.9.0-4 * libcbor-devel-0.9.0-4 libcbor is a C library for parsing and generating CBOR. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libfido2 1.12.0-1
The following packages have been uploaded to the Cygwin distribution: * libfido2-1.12.0-1 * libfido2-devel-1.12.0-1 libfido2 provides library functionality and command-line tools to communicate with a FIDO device over USB, and to verify attestation and assertion signatures. libfido2 supports the FIDO U2F (CTAP 1) and FIDO 2.0 (CTAP 2) protocols. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] tin 2.6.2-1
The following packages have been uploaded to the Cygwin distribution: * tin-2.6.2-1 Tin is a basic, easy to use Internet news reader. Tin can read news locally or remotely via an NNTP (Network News Transport Protocol) server. Install tin if you need a basic news reader. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [bug?] cygwin cannot mount smb shares beginning with underscore; "Invalid argument"
On Jan 21 11:30, Jeremy Hetzler via Cygwin wrote: > All, > > First, thank you for many years of Cygwin. > > I'm unable to get Cygwin to mount Windows SMB shares where the share > name begins with underscore. mount gives an error "Invalid argument". Yes, that's actually a bug. The mount code path in Cygwin checks the path for being a share (i.e. \\server\share\... syntax) The code, which, incidentally, has only been marginally changed since its inception pre-2000, is expecting that server name as well as share name both start with an alphanumeric ASCII char. That means, right now you can't mount servers and shares starting with any character other than [0-9a-zA-Z]. D'oh. I pushed a patch and the Cygwin test release 3.5.0-0.138.g6338d2f24a60 is building while I'm replying. Should be up in an hour or so. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: observation: masses of requests to LDAP
On Jan 22 15:32, Tobias Wendorff via Cygwin wrote: > Hi there, > > our IT department has informed me that masses of requests are being sent > from my computer to our two LDAP servers on port 389. After a detailed > investigation, the problem could be clearly traced back to "cygwin". > > Firewall logs show that about any tool, even base tools "sort" or "less", > initiates a request to port 389 on our LDAP servers. > > Sorry, I am _not_ going to release "cygcheck.out" to public, since it > contains sensitive information about the domain and its groups and > memberships. > > Even after reinstalling cygwin from another server, the problem still > appears. Could it be that this is part of an attack? No, it's working as designed. User info is fetched from AD via LDAP. If it's an overwhemling number of LDAP requests, I suspect you're often calling Cygwin processes from Windows directly, e. g., from CMD or powershell. The number of LDAP requests should be much reduced when working from a Cygwin shell, e.g., from bash in mintty due to user and group info cashing within a Cygwin process tree (Cygwin child processes get the cashed info from their Cygwin parent). If you want to reduce LDAP access even further, you can either go back to creating local /etc/passwd and /etc/group files and change /etc/nsswitch.conf accordingly(*), or you can start cygserver as a service in background(**). HTH, Corinna (*) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-nsswitch (**) https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-mapping-caching -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] getent 2.18.90-5
The following packages have been uploaded to the Cygwin distribution: * getent-2.18.90-5 The getent command displays entries from databases supported by the Name Service Switch libraries, which are configured in /etc/nssâ witch.conf. If one or more key arguments are provided, then only the entries that match the supplied keys will be displayed. Otherwise, if no key is provided, all entries will be displayed (unless the database does not support enumeration). -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [bug?] cygwin cannot mount smb shares beginning with underscore; "Invalid argument"
On Jan 22 12:56, Brian Inglis via Cygwin wrote: > On 2023-01-22 12:21, Corinna Vinschen via Cygwin wrote: > > On Jan 21 11:30, Jeremy Hetzler via Cygwin wrote: > > > First, thank you for many years of Cygwin. > > > > > > I'm unable to get Cygwin to mount Windows SMB shares where the share > > > name begins with underscore. mount gives an error "Invalid argument". > > > > Yes, that's actually a bug. The mount code path in Cygwin checks > > the path for being a share (i.e. \\server\share\... syntax) > > > > The code, which, incidentally, has only been marginally changed since > > its inception pre-2000, is expecting that server name as well as share > > name both start with an alphanumeric ASCII char. > > > > That means, right now you can't mount servers and shares starting with > > any character other than [0-9a-zA-Z]. D'oh. > > https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/naming-conventions-for-computer-domain-site-ou > > looks like embedded not initial or final "-" hyphen/minus is also allowed as > well as an initial "_" underscore like DNS names. I also checked https://answers.microsoft.com/en-us/windows/forum/all/which-characters-are-acceptable-for-a-computer/fddb4895-4295-47ab-a2b9-7773b329718c and pushed another patch to distinguish valid chars for server name and share name. The Cygwin test release containing this patch, 3.5.0-0.139.gcad3913ed8b1, is just being built. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: TMP and TMPDIR mapping
On Jan 27 09:08, john daintree via Cygwin wrote:
> Hi Audrey.
>
> Here's an example of what's going on:
>
> >>: export TMPDIR=/cygdrive/c/tmp/jd
> >>: export TMPDIR2=/cygdrive/c/tmp/jd2
> >>: cmd.exe
> Microsoft Windows [Version 10.0.22621.1105]
> (c) Microsoft Corporation. All rights reserved.
>
> C:\>echo %TMPDIR%
> C:\tmp\jd
>
> C:\>echo %TMPDIR2%
> /cygdrive/c/tmp/jd2
>
> So, if I set TMPDIR and TMPDIR2 in bash, and then call cmd.exe then TMPDIR
> is changed to c:\tmp\jd but TMPDIR2 is left as /cygdrive/c/tmp/jd2
>
> I was hoping that there's something I can do to get the following in
> cmd.exe:
>
> C:\>echo %TMPDIR2%
> C:\tmp\jd2 # TMPDIR2 "mapped"
> to c:\ in the same way that TMPDIR is
>
> I hope that's a clearer example.
>
> Note that the actual use case is calling other Win32 programs, and the
> environment variable name is different, but the above example is an attempt
> to simplify the repro.
> $PATH is mapped in a similar way. So I assume that there is a list of names
> which are mapped. I'd like to be able to add my own names to that list.
Easy: Don't call the affected Win32 executable directly. Call it
through a child process.
Two scenarios:
- Starting the nativ executable from a shell or a Makefile:
Create a wrapper script which calls
TMPDIR2="$(cygpath -wa ${TMPDIR2})
before calling your native app.
- Starting the nativ executable from your own process:
After fork(), call
const char *tmpdir2_old;
char *tmpdir2_new;
tmpdir2_old = getenv ("TMPDIR2");
tmpdir2_new = (char *) cygwin_create_path (CCP_POSIX_TO_WIN_A,
tmpdir2_old);
setenv ("TMPDIR2", tmpdir2_new, 1);
free (tmpdir2_new);
Then call execve or friends. Alternatively you can construct the
new environment like the above for any exec call taking an
environment as argument, i.e, execve, execle, execvpe.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ioperm / iopl / pciutils
On Jan 29 18:22, Franz Fehringer via Cygwin wrote: > Hi all, > > Is there any Cygwin package providing the iopl et al. routines? > Google uncovers an ioperm package but that seems to be nothing current. > My goal is to compile https://github.com/pciutils/pciutils with Cygwin. Cygwin doesn't have any Linux-like or POSIX-like API (device names, ioctl's and whatnot) to access PCI directly. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: ioperm / iopl / pciutils
On Feb 2 08:40, Franz Fehringer via Cygwin wrote: > Am 02.02.2023 um 08:33 schrieb Franz Fehringer via Cygwin: > > Am 31.01.2023 um 10:27 schrieb Corinna Vinschen via Cygwin: > > > On Jan 29 18:22, Franz Fehringer via Cygwin wrote: > > > > Hi all, > > > > > > > > Is there any Cygwin package providing the iopl et al. routines? > > > > Google uncovers an ioperm package but that seems to be nothing current. > > > > My goal is to compile https://github.com/pciutils/pciutils with Cygwin. > > > > > > Cygwin doesn't have any Linux-like or POSIX-like API (device names, > > > ioctl's and whatnot) to access PCI directly. > > > > > > > > > Corinna > > > > > > > On https://github.com/pciutils/pciutils the claim is > > > > In runs on the following systems: > > Linux (via /sys/bus/pci, /proc/bus/pci or i386 ports) > > > > and http://ftp.uni-kl.de/pub/windows/cygwin/release/ioperm/setup.hint says > > > > # $Id: setup.hint,v 1.4 2003/01/31 14:58:56 telka Exp $ > > > > sdesc: "support for ioperm()/iopl() functions" > > ldesc: "This package adds support for ioperm()/iopl() functions to Cygwin. > > This support includes sys/io.h and sys/perm.h header files together > > with development and runtime libraries." > > category: Devel Libs System > > requires: cygwin libpopt0 > > > > So there possibly was once iopl support? I was just trying to say that Cygwin itself (i. e., the core DLL) does not provide any such calls or headers. > Just guessing this was possibly 32bit only. Very likely. Looks like we never had an ioperm package for 64 bit, and that makes sense. You'd have to build the ioperm package by yourself for 64 bit, and you'll have a few problems there. - Checking the package for type safety. Think LP64 vs. LLP64 https://cygwin.com/faq.html#faq.programming.64bitporting - The ioperm package can only provide these calls by installing a kernel driver (see the source, driver subdir). - This driver may or may not work on 64 bit, but if it works, you can only install it by switching your machine into debug mode: https://learn.microsoft.com/en-us/windows-hardware/drivers/install/installing-an-unsigned-driver-during-development-and-test - For normal operations you have to sign the driver. Self-signed drivers won't run on any machine with UEFI secure boot enabled. Alternatively you can let Microsoft sign it. Only that version would be ok for inclusion into the Cygwin distro. - Alternatively you can try to convert the ioperm driver into an UMDF driver. Some kernel functionality is not allowed for UMDF drivers, but I never looked deeper into this. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] openssh 9.2p1-1
The following packages have been uploaded to the Cygwin distribution:
* openssh-9.2p1-1
OpenSSH is a program for logging into a remote machine and for
executing commands on a remote machine. It can replace rlogin and rsh,
providing encrypted communication between two machines.
Upstream announcement:
OpenSSH 9.2 released
OpenSSH 9.2 has just been released. It will be available from the
mirrors listed at https://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support.
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
https://www.openssh.com/donations.html
Changes since OpenSSH 9.1
=
This release fixes a number of security bugs.
Security
This release contains fixes for two security problems and a memory
safety problem. The memory safety problem is not believed to be
exploitable, but we report most network-reachable memory faults as
security bugs.
* sshd(8): fix a pre-authentication double-free memory fault
introduced in OpenSSH 9.1. This is not believed to be exploitable,
and it occurs in the unprivileged pre-auth process that is
subject to chroot(2) and is further sandboxed on most major
platforms.
* ssh(8): in OpenSSH releases after 8.7, the PermitRemoteOpen option
would ignore its first argument unless it was one of the special
keywords "any" or "none", causing the permission list to fail open
if only one permission was specified. bz3515
* ssh(1): if the CanonicalizeHostname and CanonicalizePermittedCNAMEs
options were enabled, and the system/libc resolver did not check
that names in DNS responses were valid, then use of these options
could allow an attacker with control of DNS to include invalid
characters (possibly including wildcards) in names added to
known_hosts files when they were updated. These names would still
have to match the CanonicalizePermittedCNAMEs allow-list, so
practical exploitation appears unlikely.
Potentially-incompatible changes
* ssh(1): add a new EnableEscapeCommandline ssh_config(5) option that
controls whether the client-side ~C escape sequence that provides a
command-line is available. Among other things, the ~C command-line
could be used to add additional port-forwards at runtime.
This option defaults to "no", disabling the ~C command-line that
was previously enabled by default. Turning off the command-line
allows platforms that support sandboxing of the ssh(1) client
(currently only OpenBSD) to use a stricter default sandbox policy.
New features
* sshd(8): add support for channel inactivity timeouts via a new
sshd_config(5) ChannelTimeout directive. This allows channels that
have not seen traffic in a configurable interval to be
automatically closed. Different timeouts may be applied to session,
X11, agent and TCP forwarding channels.
* sshd(8): add a sshd_config UnusedConnectionTimeout option to
terminate client connections that have no open channels for a
length of time. This complements the ChannelTimeout option above.
* sshd(8): add a -V (version) option to sshd like the ssh client has.
* ssh(1): add a "Host" line to the output of ssh -G showing the
original hostname argument. bz3343
* scp(1), sftp(1): add a -X option to both scp(1) and sftp(1) to
allow control over some SFTP protocol parameters: the copy buffer
length and the number of in-flight requests, both of which are used
during upload/download. Previously these could be controlled in
sftp(1) only. This makes them available in both SFTP protocol
clients using the same option character sequence.
* ssh-keyscan(1): allow scanning of complete CIDR address ranges,
e.g. "ssh-keyscan 192.168.0.0/24". If a CIDR range is passed, then
it will be expanded to all possible addresses in the range
including the all-0s and all-1s addresses. bz#976
* ssh(1): support dynamic remote port forwarding in escape
command-line's -R processing. bz#3499
Bugfixes
* ssh(1): when restoring non-blocking mode to stdio fds, restore
exactly the flags that ssh started with and don't just clobber them
with zero, as this could also remove the append flag from the set.
bz3523
* ssh(1): avoid printf("%s", NULL) if using UserKnownHostsFile=none
and a hostkey in one of the system known hosts file changes.
* scp(1): switch scp from using pipes to a socket-pair for
communication with its ssh sub-processes, matching how sftp(1)
operates.
* sshd(8): clear signal mask early in main(); sshd may have been
started with one or more signals masked (sigprocmask(2) is not
cleared on fork/exe
[ANNOUNCEMENT] cygrunsrv 1.63-1
The following packages have been uploaded to the Cygwin distribution: * cygrunsrv-1.63-1 Adding two options -T and -X to control timeouts when starting/stopping the service. Rearranging the package build system. Windows provides a set of functions required to be called by applications supposed to run as a service. The usual POSIX daemon is not prepared to do so, so it can't run as a service under Windows. Cygrunsrv is a Windows service application, acting as a wrapper between the POSIX daemon and the Windows system. For usage info, read the file /usr/share/doc/Cygwin/cygrunsrv.README. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv -L error
On Feb 5 09:15, Doug Henderson via Cygwin wrote: > Hi, > > I tried to run "cygrunsrc -L" in both a regular and elevated shell. In both > cases I received the same error messages. I do not believe I have any > cygwin services configured. > > $ cygrunsrv -L > cygrunsrv: warning: QueryServiceConfig failed for 'dcsvc': Win32 error 2 > The system cannot find the file specified. > cygrunsrv: warning: QueryServiceConfig failed for 'McpManagementService': > Win32 error 15100 > The resource loader failed to find MUI file. I checked that I have a dcsvc service installed, but I don't have the McpManagementService (something with Office 365, apparently). I can't reproduce the above, not even the dcsvc warning. Neither with the latest, nor with the previous version of cygrunsrv. I searched the web and apparently both errors are known, independently from cygrunsrv or Cygwin, for instance: https://www.reddit.com/r/PowerShell/comments/xod7nu/getservice_error/ https://ugetfix.com/ask/how-to-fix-mcpmanagementservice-error-code-15100-in-windows/ The problem here is that you see the warnings, I assume? You can avoid seeing them by redirecting stderr to /dev/null. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] recode 3.7.12-1
The following packages have been uploaded to the Cygwin distribution: * recode-3.7.12-1 * librecode3-3.7.12-1 * recode-devel-3.7.12-1 The 'recode' converts files between character sets and usages. It recognises or produces nearly 150 different character sets and is able to transliterate files between almost any pair. When exact transliteration are not possible, it may get rid of the offending characters or fall back on approximations. Most RFC 1345 character sets are supported. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygrunsrv 1.64-1
The following packages have been uploaded to the Cygwin distribution: * cygrunsrv-1.64-1 This release contains a change which is supposed to handle quoted service application paths to be handeled sanely. Windows provides a set of functions required to be called by applications supposed to run as a service. The usual POSIX daemon is not prepared to do so, so it can't run as a service under Windows. Cygrunsrv is a Windows service application, acting as a wrapper between the POSIX daemon and the Windows system. For usage info, read the file /usr/share/doc/Cygwin/cygrunsrv.README. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: cygrunsrv -L outputs nothing if service paths are quoted
On Feb 6 08:43, Bill Stewart via Cygwin wrote: > FYI: > > In our corporate environment we run vulnerability scans, and one of the > most common complaints of the scanner is "unquoted service paths." > > To fix this "vulnerability," I use a quoted service path for cygrunsrv.exe; > e.g.: > > "C:\Program Files\Cygwin\cygrunsrv.exe" > > This seems to confuse cygrunsrv -L, though, as it produces no output. Yeah, quoted paths were not handled at all. I pushed a new version 1.64 which contains a patch. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] rlwrap 0.46.1-2
The following packages have been uploaded to the Cygwin distribution: * rlwrap-0.46.1-2 rlwrap is a readline wrapper that uses the GNU readline library to allow the editing of keyboard input for any other command. Input history is remembered across invocations, separately for each command; history completion and search work as in bash and completion word lists can be specified on the command line. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH_9.2p1 sftp prompt now "s " instead of "sftp> "
On Feb 8 07:59, Thomas Wolff via Cygwin wrote: > > > Am 08.02.2023 um 03:17 schrieb Brian Inglis via Cygwin: > > On 2023-02-07 15:22, Voris, Ben via Cygwin wrote: > > > For example: > > > : sftp user@127.0.0.1 > > > Connected to 127.0.0.1. > > > s bye > > > : type sftp > > > sftp is hashed (/usr/bin/sftp) > > > : ssh -V > > > OpenSSH_9.2p1, OpenSSL 1.1.1s 1 Nov 2022 > > > On Linux with a much older ssh: > > > : ssh -V > > > OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 > > > : sftp user@127.0.0.1 > > > Connected to 127.0.0.1. > > > sftp> bye > > > Windows 10 21H2. This occurs both using Mintty and Windows Terminal. > > > For what I do, the only issue is the prompt. > > > > ++ > > > Yes, it sends s^[[7G^D, which is really weird. Looks like this occurs in libedit. Downgrading to the former version of libedit "fixes" the problem. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libedit 20221030-4
The following packages have been uploaded to the Cygwin distribution: * libedit-devel-20221030-4 * libedit0-20221030-4 This release is supposed to fix the problem outlined in https://cygwin.com/pipermail/cygwin/2023-February/253029.html Libedit is an autotool- and libtoolized port of the NetBSD Editline library. It provides generic line editing, history, and tokenization functions, similar to those found in GNU Readline. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: OpenSSH_9.2p1 sftp prompt now "s " instead of "sftp> "
On Feb 8 11:12, Corinna Vinschen via Cygwin wrote: > On Feb 8 07:59, Thomas Wolff via Cygwin wrote: > > > > > > Am 08.02.2023 um 03:17 schrieb Brian Inglis via Cygwin: > > > On 2023-02-07 15:22, Voris, Ben via Cygwin wrote: > > > > For example: > > > > : sftp user@127.0.0.1 > > > > Connected to 127.0.0.1. > > > > s bye > > > > : type sftp > > > > sftp is hashed (/usr/bin/sftp) > > > > : ssh -V > > > > OpenSSH_9.2p1, OpenSSL 1.1.1s 1 Nov 2022 > > > > On Linux with a much older ssh: > > > > : ssh -V > > > > OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f 31 Mar 2020 > > > > : sftp user@127.0.0.1 > > > > Connected to 127.0.0.1. > > > > sftp> bye > > > > Windows 10 21H2. This occurs both using Mintty and Windows Terminal. > > > > For what I do, the only issue is the prompt. > > > > > > ++ > > > > > Yes, it sends s^[[7G^D, which is really weird. > > Looks like this occurs in libedit. Downgrading to the former > version of libedit "fixes" the problem. You may want to try the new libedit release 2021030-4. Thanks to Christoph Reiter from the MSYS2 community for pointing out a patch. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] pl 8.4.3-1
The following packages have been uploaded to the Cygwin distribution: * pl-8.4.3-1 * pl-devel-8.4.3-1 * pl-doc-8.4.3-1 * pl-odbc-8.4.3-1 * pl-xpce-8.4.3-1 ISO/Edinburgh-style Prolog compiler including modules, auto-load, libraries, Garbage-collector, stack-expandor, C/C++-interface, GNU-readline interface, very fast compiler. Including packages clib (Unix process control and sockets), cpp (C++ interface), sgml (reading XML/SGML), sgml/RDF (reading RDF into triples) and XPCE (Graphics UI toolkit, integrated editor (Emacs-clone) and source-level debugger). -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod g+ws unsuccessful, "NULL SID" icacls missing
Hi Norton, On Feb 9 13:25, Norton Allen via Cygwin wrote: > On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote: > > I briefly raised this issue months ago and am trying to resolve it again > > now. > > > > What I am trying to do is setup permissions so multiple users on one > > machine can share full control over a particular directory hierarchy. > > > > On Linux I have usually been able to make things work with: > > > > $ mkdir shared_dir > > $ chgrp shared_group shared_dir > > $ chmod g+ws shared_dir > > $ umask 2 > > > > User shells are configured with umask 2 so files they create have group > > write. Users belong to shared_group. Files and subdirs created under > > shared_dir are all in group shared_group. Files moved in retain their > > original group, but the group members still have permission to rename or > > delete them. > > > > The problem: > > > > $ chmod g+ws fails to set the 's' bit, and the resulting icacls output > > does not contain any "NULL SID" entries. I am seeing the same problem on > > (at least) two different systems setup by my organization. One of these > > was just re-imaged and I installed Cygwin yesterday with no customized > > configurations. AV is Windows Defender, but I suspect if that were the > > culprit, there would have been more noise. > > > > I suspect there might be a group policy or something that is interfering > > with Cygwin's strategy for implementing POSIX permissions. I am pretty > > sure this worked correctly at some point in the past. > > > > Has anyone encountered this? > > > > Does group policy seem like a likely suspect? Anyone know which > > policy(ies)? I think I might be able to get IT to cut me slack if I knew > > what to ask for. > > > > I have also played with using setfacl directly to add permissions, but > > as anyone who has read about Cygwin file permissions might guess, that > > tends to have mixed/poor results, but I'd be open to any suggestions. > > > > I don't actually have a system on which this is working to compare to, so I > am not exactly sure how it is supposed to look when it's working correctly. > The current behavior on my new uncustomized installation: > [...] > Any idea what g+s should be doing? Any more/better information I can > provide? What you observe is a bug in Cygwin, plain and simple. Without going into too much detail, part of the problem could never be observed with older coreutils, which we had to live with for much too long in the Cygwin distro. The newer coreutils handles permissions slightly differently and that dropped the mask from the buggy code. I applied a patch which, hopefully, fixes this problem (in fact, plural, "these problems"). A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built and should be up in an hour or so. You can simply install it via Cygwin's setup tool as soon as it's on your favorite mirror. If it works as desired, it will be part of the next Cygwin bugfix release 3.4.6. Thanks, Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: chmod g+ws unsuccessful, "NULL SID" icacls missing
On Feb 10 11:42, Norton Allen via Cygwin wrote: > On 2/9/2023 4:09 PM, Corinna Vinschen wrote: > > On Feb 9 13:25, Norton Allen via Cygwin wrote: > > > On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote: > > > > [...] > > > > The problem: > > > > > > > > $ chmod g+ws fails to set the 's' bit, and the resulting icacls output > > > > does not contain any "NULL SID" entries. I am seeing the same problem on > > > > (at least) two different systems setup by my organization. One of these > > > > was just re-imaged and I installed Cygwin yesterday with no customized > > > > configurations. AV is Windows Defender, but I suspect if that were the > > > > culprit, there would have been more noise. > > > > [...] > > > [...] > > > Any idea what g+s should be doing? Any more/better information I can > > > provide? > > What you observe is a bug in Cygwin, plain and simple. Without going > > into too much detail, part of the problem could never be observed with > > older coreutils, which we had to live with for much too long in the > > Cygwin distro. The newer coreutils handles permissions slightly > > differently and that dropped the mask from the buggy code. > > > > I applied a patch which, hopefully, fixes this problem (in fact, plural, > > "these problems"). > > > > A new Cygwin test release 3.5.0-0.162.g498fce80ef33 is just being built > > and should be up in an hour or so. You can simply install it via > > Cygwin's setup tool as soon as it's on your favorite mirror. > > > > If it works as desired, it will be part of the next Cygwin bugfix > > release 3.4.6. > > Corinna, > > The fix seems to work like a charm! And I am happy to be wrong about the > source of the problem. Great, thanks for testing! Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libmd 1.0.4-3
The following packages have been uploaded to the Cygwin distribution:
* libmd0-1.0.4-3
* libmd-devel-1.0.4-3
The libmd library provides a few message digest ('hash') functions, as
found on various BSD systems, either on their libc or on a library with
the same name, and with a compatible API.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libbsd 0.11.7-3
The following packages have been uploaded to the Cygwin distribution: * libbsd0-0.11.7-3 * libbsd-devel-0.11.7-3 libbsd provides useful functions commonly found on BSD systems, and lacking on others like GNU systems, thus making it easier to port projects with strong BSD origins, without needing to embed the same code over and over again on each project. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] libretls 3.7.0-1
The following packages have been uploaded to the Cygwin distribution: * libretls26-3.7.0-1 * libretls-devel-3.7.0-1 LibreTLS is a port of libtls from LibreSSL to OpenSSL. OpenBSD's libtls is a new TLS library, designed to make it easier to write foolproof applications. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
On Feb 12 22:03, Cygwin dash Co-Maintainer via Cygwin-announce via Cygwin wrote: > The following packages have been upgraded in the Cygwin distribution: > > * dash0.5.12-2 > > This package is being upgraded to current as the previous release > breaks existing function that may be relied on by some scripts. > This release has been rebuilt disabling libc fnmatch and glob as > Cygwin/winsup/newlib do not support locale dependent named character > classes like glibc. So how do we fix in Cygwin without pulling in GLibc code? Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] netcat 1.219-2
The following packages have been uploaded to the Cygwin distribution: * netcat-1.219-2 This package replaces the old "nc" and "nc6" packages. The tool is still called "nc", the build system is now based on the "netcat" package from the Fedora Linux distro. The OpenBSD nc (or netcat) utility can be used for just about anything involving TCP, UDP, or UNIX-domain sockets. It can open TCP connections, send UDP packets, listen on arbitrary TCP and UDP ports, do port scanning, and deal with both IPv4 and IPv6. Unlike telnet(1), nc scripts nicely, and separates error messages onto standard error instead of sending them to standard output, as telnet(1) might do with some. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
Hi Brian, On Feb 13 10:22, Corinna Vinschen via Cygwin wrote: > On Feb 12 22:03, Cygwin dash Co-Maintainer via Cygwin-announce via Cygwin > wrote: > > The following packages have been upgraded in the Cygwin distribution: > > > > * dash 0.5.12-2 > > > > This package is being upgraded to current as the previous release > > breaks existing function that may be relied on by some scripts. > > This release has been rebuilt disabling libc fnmatch and glob as > > Cygwin/winsup/newlib do not support locale dependent named character > > classes like glibc. Can you give me an example? I'm a bit puzzled because fnmatch as well as glob in Cygwin support native characters. Corinna > > So how do we fix in Cygwin without pulling in GLibc code? > > > Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: dash 0.5.12-2
On Feb 13 12:03, Brian Inglis via Cygwin wrote: > On 2023-02-13 10:43, ASSI via Cygwin wrote: > > Corinna Vinschen via Cygwin writes: > > > On Feb 12 22:03, Cygwin dash Co-Maintainer wrote: > > > > The following packages have been upgraded in the Cygwin distribution: > > > > > > > > * dash0.5.12-2 > > > > > > > > This package is being upgraded to current as the previous release > > > > breaks existing function that may be relied on by some scripts. > > > > This release has been rebuilt disabling libc fnmatch and glob as > > > > Cygwin/winsup/newlib do not support locale dependent named character > > > > classes like glibc. > > > > Can you give me an example? I'm a bit puzzled because fnmatch as well > > > as glob in Cygwin support native characters. > > But not locale dependent named character classes like regexp in paths. I checked the dash code of curent dash git, and while its internal glob implementation supports character classes, they are no localized, using standard singlebyte functions isalnum, isalpha, etc. under the hood. So, yeah, what you say further down this mail... looks like dash supports locale dependent character classes only with glibc. > > AFAIU, the issue was with locale dependent character classes, not > > characters. Andrey specifically mentioned [[:space:]] in the original > > bugreport. > > Specifically support in fnmatch and glob, now updated in glibc, and their > use in dash for parameter expansion in place of (gnulib?) regexp support. > > > > So how do we fix in Cygwin without pulling in GLibc code? > > It's fixed in release 2 which disables 0.5.12 changed default (using > [Cygwin/winsup/newlib] libc fnmatch and glob, without testing > functionality), and goes back to using its own previous default (gnulib?) > regexp code for parameter expansion which supports locale dependent named > character classes. > > As glibc "recently" fixed their fnmatch and glob to support locale dependent > named character classes like [[:blank:]], dash decided to use those in > parameter expansions for consistency, but not exactly clearly documented, > although they added config options to enable/disable each of libc > fnmatch/glob. > > Cygwin bash parameter expansion also supports locale dependent named > character classes. > > $ info bash pattern > $ info sed classes These info pages are mostly target-system independent. There's no guarantee that this works in a Cygwin bash or sed. Either way, I don't care much for what a certain application provides by itself. I'm talking about our libc, that is Cygwin, and what it provides to processes calling its implementations of regcomp/regexec, glob and fnmatch. All these functions have been taken from FreeBSD and all three suffer shortcomings: - regcomp/regexec supports POSIX named character classes, collating symbols, and equivalence class expressions, but all of them only work for ASCII chars. - fnmatch and glob support neither of named character classes, collating symbols, and equivalence class expressions. I checked the upstream code in FreeBSD, OpenBSD and NetBSD and none of these functions are improved to support locales (regcomp) or any of the character classes stuff (fnmatch/glob). So, if we want to add this support to Cygwin (and thus, to all applications calling the libc implementation of these functions), quite a bit of work is required. Being able to fetch the implementation from some other source would reduce the effort enourmously :} Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] cygwin 3.4.6-1
The following packages have been uploaded to the Cygwin distribution: * cygwin-3.4.6-1 * cygwin-devel-3.4.6-1 * cygwin-doc-3.4.6-1 Bug Fixes - Fix a problem that fsync returns EINVAL for block device. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252916.html Don't reject valid server and share names when mounting. Addresses: https://cygwin.com/pipermail/cygwin/2023-January/252928.html Create directories with correctly umask-filtered default ACEs. Addresses: https://cygwin.com/pipermail/cygwin/2023-February/253037.html Don't accidentally drop the default ACEs when chmod'ing directories. Addresses: https://cygwin.com/pipermail/cygwin/2023-February/253037.html -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
