https://cygwin.com/pipermail/cygwin/2022-December/252737.html
If the less is started from non-cygwin shell and window size is
changed, it will hang-up when quitting. The cause of the proglem is
that less uses longjump() in signal handler. If the signal handler
is called while cygwin is acquiring the mutex, cygwin loses the
chance to release mutex. With this patch, the mutex is released
just before calling kill_pgrp() and re-acquired when kill_pgrp()
returns.
Reported-by: Gregory Mason <grmason@epic.com>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Commit c1023ee353 introduced a split between mount flags and
path flags. It didn't initialize symlink_info::path_flags in
path_conv::check, because that's done in symlink_info::check.
However, there are two code paths expecting symlink_info::path_flags
being already initialized and both skip symlink_info::check.
Make sure symlink_info::path_flags is initalized to 0 early in
path_conv::check.
Fixes: c1023ee353 ("Cygwin: path_conv: decouple path_types from mount types")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
https://cygwin.com/pipermail/cygwin/2022-December/252628.html
After the commit 9e4d308cd5, the performance of read from non-cygwin
pipe has been degraded. This is because select_sem mechanism does not
work for non-cygwin pipe. This patch fixes the issue.
Fixes: 9e4d308cd5 ("Cygwin: pipe: Adopt FILE_SYNCHRONOUS_IO_NONALERT
flag for read pipe.")
Reported-by: tryandbuy <tryandbuy@proton.me>
Reviewed-by: Corinna Vinschen <corinna@vinschen.de>
Signed-off-by: Takashi Yano <takashi.yano@nifty.ne.jp>
Commit 188d5f6c9a erroneously moved the mcountFunc.S file to the
TARGET_FILES target, rather than keeping it in GMON_FILES. The
result is that the __fentry__ entry point is now entirely undefined,
so `gcc -pg' is broken.
Create new target-specific GMON_TARGET_FILES and move mcountFunc.S
into it. Add $(GMON_TARGET_FILES) to GMON_FILES.
Fixes: 188d5f6c9a ("Cygwin: x86_64: add wmemset assembler entry point")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
.com is a remnant from the past. There are only five executables
left:
chcp.com
format.com
mode.com
more.com
tree.com
Calling them on the command line already requires to use the
suffix anyway. So drop useless .com test from the execve test
for scripts (they are handled earlier in the same function
as executables) and do not handle them like .exe suffixes in
other functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
According to POSIX and the Linux man page, select(2) is supposed to
report read ready if a file is at EOF. In the case of a FIFO, this
means that the pipe is empty and there are no writers. But there
seems to be an undocumented exception, observed on Linux and other
platforms: If no writer has ever been opened, then select(2) does not
report read ready. This can happen if a reader is opened with
O_NONBLOCK before any writers have opened.
This commit makes Cygwin consistent with those other platforms by
introducing a special EOF test, fhandler_fifo::select_hit_eof, which
returns false if there's never been a writer opened.
To implement this we use a new variable '_writer_opened' in the FIFO's
shared memory, which is set to 1 the first time a writer opens. New
methods writer_opened() and set_writer_opened() are used to test and
set this variable.
Addresses: https://cygwin.com/pipermail/cygwin/2022-September/252223.html
This simple testcase:
locale_t st = newlocale(LC_ALL_MASK, "C", (locale_t)0);
locale_t st2 = newlocale(LC_CTYPE_MASK, "en_US.UTF-8", st);
is sufficient to reproduce a crash in _newlocale_r. After the first call
to newlocale, `st' points to __C_locale, which is const. When using `st'
as locale base in the second call, _newlocale_r tries to set pointers
inside base to NULL. This is bad if base is __C_locale, obviously.
Add a test to avoid trying to overwrite pointer values inside base if
base is __C_locale.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Currently it is possible for symlink_info::check to return -1 in case
we're searching for foo and find foo.lnk that is not a Cygwin symlink.
This contradicts the new meaning attached to a negative return value
in commit 19d59ce75d. Fix this by setting "res" to 0 at the beginning
of the main loop and not seting it to -1 later.
Also fix the commentary preceding the function definition to reflect
the current behavior.
Addresses: https://cygwin.com/pipermail/cygwin/2022-August/252030.html
Define FD_SETSIZE (<sys/select.h>) to be 1024 by default, and define
NOFILE (<sys/param.h>) to be OPEN_MAX (== 3200) by default.
Remove the comment in <sys/select.h> that FD_SETSIZE should be >=
NOFILE.
Bump API minor.
Addresses: https://cygwin.com/pipermail/cygwin/2022-July/251839.html
- With this patch, the empty path (empty element in PATH or PATH is
absent) is treated as the current directory as Linux does. This
feature is added for Linux compatibility, but it is deprecated.
POSIX notes that a conforming application shall use an explicit
pathname to specify the current working directory.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251730.html
This reverts commit 1f8f7e2d54, "* libc/stdio/refill.c (__srefill):
Try again after EOF on Cygwin." If EOF is set on a file, the stdio
input functions will now immediately return EOF rather than trying
again to read. This aligns Cygwin's behavior to that of Linux.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251672.html
- poll() has a bug that it returns event which is not inquired if
events are inquired in multiple pollfd entries on the same fd at
the same time. This patch fixes the issue.
Addresses: https://cygwin.com/pipermail/cygwin/2022-June/251732.html
The current definition of mknod in syscalls.cc has a third argument of
type __dev16_t instead of dev_t. Fix this on 64-bit Cygwin by making
the existing mknod 32-bit only and then exporting mknod as an alias
for mknod32. (No fix is needed on 32-bit because mknod is redirected
to mknod32 via NEW_FUNCTIONS in Makefile.am.)
Addresses: https://cygwin.com/pipermail/cygwin-developers/2022-May/012589.html
killpg(pgid, 0) (or kill_pgrp(pgid, si_signo=0), in signal.cc)
fails (returns -1) even when there is a process in the process
group pgid, if the process is in the middle of spawnve(), see
https://cygwin.com/pipermail/cygwin/2022-May/251479.html
When exec'ing a process the assumption is that the exec'ed process creates its
own symlink (in pinfo::thisproc() in pinfo.cc). If the exec'ing process
calls NtClose on it's own winpid symlink, but the exec'ed process didn't
progress enough into initialization, there's a slim chance that neither
the exec'ing process, nor the exec'ed process has a winpid symlink
attached.
Always create the winpid symlink in spawn.cc, even for exec'ed Cygwin
processes. Make sure to dup the handle into the new process, and stop
creating the winpid symlink in exec'ed processes.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
A recent patch fixed gmondump to stop printing "0x0x" as an address
prefix. It turns out the Cygwin User's Guide and the gmondump and
ssp man pages (all from utils.xml) have examples of the same error.
- As mentioned in commit message of the commit b531d6b0, if multiple
writers including non-cygwin app exist, the non-cygwin app cannot
detect pipe closure on the read side when the pipe is created by
system account or the the pipe creator is running as service.
This is because query_hdl which is held in write side also is a
read end of the pipe, so the pipe is still alive for the non-cygwin
app even after the reader is closed.
To avoid this problem, this patch lets all processes in the same
process group close query_hdl using newly introduced internal signal
__SIGNONCYGCHLD when non-cygwin app is started.
Addresses: https://cygwin.com/pipermail/cygwin/2022-March/251097.html
This reverts commit 0390cc8572.
There's no indication what exact situation this patch was supposed to
solve, and local testing doesn't show any such problems. However, this
patch itself introduced a new problem, as outlined by
https://cygwin.com/pipermail/cygwin/2022-January/250629.html
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
32 bit Cygwin still exports function calls to support old applications.
E. g., when switching from 16 to 32 bit uid/gid values, new function
like getuid32 have been added and the old getuid function still only
provides 16 bit values. Newly built applications using getuid are
actually calling getuid32.
However, this link magic isn't performed inside Cygwin itself, so if
newlib functions call getuid, they actually call the old getuid, not
the new getuid32. This leads to truncated uid/gid values.
https://cygwin.com/pipermail/cygwin/2022-January/250453.html reports
how this leads to problems in posix_spawn.
Fix this temporarily. i686 support will go away soon in Cygwin and the
fix can be dropped.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
get_posix_access() creates DEF_*_OBJ aclent_t entries from Windows ACEs
with INHERIT flags set, independent of the file type. These flags only
make sense on directory objects, but certain Windows functions don't
check the file type and allow INHERIT ACE flags even on non-directories.
As a fix, make sure to ignore the INHERIT flags on non-directory ACLs
and don't propagate the matching DEF_*_OBJ aclent_t entries to callers.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
NtQueryInformationProcess(ProcessHandleInformation) can return
STATUS_SUCCESS with invalid handle data for certain processes
("minimal" processes on Windows 10). This can cause a crash when
there's an attempt to access that data. Fix that by setting
NumberOfHandles to zero before calling NtQueryInformationProcess.
Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html
- This patch fixes the bug that input is wrongly sent to io_handle_nat
rather than io_handle when neither read() nor select() is called
after the cygwin app is started from non-cygwin app. This happens
only if psuedo console is disabled.
Addresses:
https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html
Takashi Yano
Corinna Vinschen
Jon Turney
Ken Brown
Mark Geisert