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