Rather than waiting for signalfd_select_wait in a thread, which is racy,
create a global event "my_pendingsigs_evt" which is set and reset by
wait_sig depending only on the fact if blocked signals are pending or not.
This in turn allows to WFMO on this event in select as soon as signalfds
are present in the read descriptor set. Select's peek and verify
will then check if one of the present signalfds is affected.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Borrow a trick from strace to lessen occurrences of "??? => ???" in ldd
output. Specifically, if the module name isn't found in the usual place
in the mapped image, use the file handle we have to look up the name.
On sigwaitinfo or reading from a signalfd, signal processing sets up
signal handling via sigdelayed even if the handler address is NULL.
This doesn't have any impact on sigwaitinfo scenarios (or at least, I
wasn't able to come up with a reproducer) but it breaks signalfd
scenarios, where eventually a call to call_signal_handler from
sigdelayed will try to call the NULL function.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- If screen is alternated on console, cursor position is not restored
correctly in the case of xterm compatible mode is enabled. For example,
the shell prompt is shown at incorrect position after using vim.
This patch fixes this problem.
- The horizontal tab positions are broken after resizing console window.
This seems to be a bug of xterm compatible mode of windows console.
This workaround fixes this problem.
The default implementation of the fenv.h methods return
-EOPNOTSUP. Some of these have implementations appropriate
for soft-float.
The intention of the new fenv.h is that it be portable
and that architectures provide their own implementation
of sys/fenv.h.
This avoids collisions of shmat maps with Windows own datastructures
when allocating top-down.
This patch moves the mmap_allocator class definition into its
own files and just uses it from mmap and shmat.
Adding default winvar 'PATH=C:\cygwin64\binZ' to an environment that is
already allocated for 'SYSTEMROOT=ZWINDIR=Z', we need to count that
trailing (Z)ero as well. Otherwise we trigger this assertion failure:
$ /bin/env -i SYSTEMROOT= WINDIR= /bin/env
assertion "(s - envblock) <= tl" failed: file "/home/corinna/src/cygwin/cygwin-3.0.7/cygwin-3.0.7-1.x86_64/src/newlib-cygwin/winsup/cygwin/environ.cc", line 1302, function: char** build_env(const char* const*, WCHAR*&, int&, bool, HANDLE)
Aborted (core dumped)
When the exec family of functions is called for a script-like
file, the av::setup function handles the exec[vl]p case as
well. The execve case for files not starting with a she-bang
is handled first by returning ENOEXEC. Only after that, the
file's executability is checked.
This leads to the problem that ENOEXEC is returned for non-executable
files as well. A calling shell interprets this as a file it should try
to run as script. This is not desired for non-executable files.
Fix this problem by checking the file for executability first. Only
after that, follow the other potential code paths.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch supplies an implementation of the CPU_SET(3) processor
affinity macros as documented on the relevant Linux man page.
There is a mostly superset implementation of cpusets under newlib's
libc/sys/RTEMS/include/sys that has Linux and FreeBSD compatibility
and is built on top of FreeBSD bitsets. This Cygwin implementation
and the RTEMS one could be combined if desired at some future point.
Do not attach to the child before it was successfully initialized, or we
would need more sophisticated cleanup on child initialization failure,
like suppressing SIGCHILD delivery with multiple threads ("waitproc")
involved.
Improves "Cygwin: fork: Remember child not before success.",
commit f03ea8e1c5, which leads to fork
problems if cygserver is running:
https://cygwin.com/ml/cygwin-patches/2019-q2/msg00155.html
During fork, the child process requires the process table to be
initialized for fixup_shms_after_fork, while still allowing subsequent
dlls.load_after_fork to fail silently (for when the "forkable" hardlinks
are not created yet).
pinfo::remember not performing reattach anymore requires explicit
pinfo::reattach now where appropriate.
Prepares to improve "Cygwin: fork: Remember child not before success."
commit f03ea8e1c5, which leads to fork
problems if cygserver is running:
https://cygwin.com/ml/cygwin-patches/2019-q2/msg00155.html
Introducing an independent Cygwin PID introduced a regression:
The expectation is that the myself pinfo pointer always points to a
specific address right in front of the loaded Cygwin DLL.
However, the independent Cygwin PID changes broke this. To create
myself at the right address requires to call init with h0 set to
INVALID_HANDLE_VALUE or an existing address:
void
pinfo::init (pid_t n, DWORD flag, HANDLE h0)
{
[...]
if (!h0 || myself.h)
[...]
else
{
shloc = SH_MYSELF;
if (h0 == INVALID_HANDLE_VALUE) <-- !!!
h0 = NULL;
}
The aforementioned commits changed that so h0 was always NULL, this way
creating myself at an arbitrary address.
This patch makes sure to set the handle to INVALID_HANDLE_VALUE again
when creating a new process, so init knows that myself has to be created
in the right spot. While at it, fix a potential uninitialized handle
value in child_info_spawn::handle_spawn.
Fixes: b5e1003722 ("Cygwin: processes: use dedicated Cygwin PID rather than Windows PID")
Fixes: 88605243a1 ("Cygwin: fix child getting another pid after spawnve")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
_pinfo::set_ctty sets myself's pgid to the ctty pgid if the process has
been started from a non-Cygwin process. This isn't the right thing to
do when started from GDB. GDB starts the application via standard
Windows means, not via Cygwin fork/exec, so it's treated as being
a non-Cygwin parent.
But we want the app running in it's own process group. So skip this
step when running under a debugger
Signed-off-by: Corinna Vinschen <corinna-cygwin@cygwin.com>
Return -1 with EINVAL if pgid < 0.
Previously tcsetpgrp() would blindly go ahead and set the pgid of the
controlling terminal to a negative value, causing later calls to
various functions to fail.
For example, gdb has code like the following:
tcsetpgrp (0, getpgid (inf->pid));
If getpgid (inf->pid) fails (returns -1), then this code would set the
pgid of fd 0 to -1, so that some later calls to getpgid() would also
return -1. This caused the problem reported here:
https://cygwin.com/ml/cygwin/2019-07/msg00166.html.
So far negative values were denoting files, positive values
denoting directories. We should prefer a less error prone
method. Redefine virtual_ftype_t to contain only positive
values and replace checks for negativ or positive values with
inline functions virt_ftype_isfile() and virt_ftype_isdir().
Drop outdcated comments referring to numerical virtual_ftype_t
values.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
commit 2607639992 "Improve error handling in /proc/[pid]/
virtual files." changed the return value of the /proc/PID
formatting functions to return -1 instead of 0 in the error
case to allow a filesize of 0.
The patch neglected to change this behaviour for /proc/PID/fd
content. This patch fixes that.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Change path_conv::is_lnk_special() so that it returns false on socket
files.
is_lnk_special() is called by rename2() in order to deal with special
files (FIFOs and symlinks, for example) whose Win32 names usually have
a ".lnk" suffix. Socket files do not fall into this category, and
this change prevents ".lnk" from being appended erroneously when such
files are renamed.
Remove a now redundant !pc.issocket() from fhandler_disk_file::link().
It is used only once, and the name is supposed to suggest "device that
is not based on the filesystem". This intended meaning is clearer if
we just replace is_auto_device() by its definition at the place where
it's used.
The sigpending mechanism failed to check if the pending signal was a
process-wide signal, or a signal for the curent thread. Fix that by
adding a matching conditional to wait_sig's __SIGPENDING code.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far sig_send's return type is int. The problem with this is
that sig_send returns a sigset_t on __SIGPENDING, and sigset_t
is defined as long type. So the function only returns the lower
32 bit of sigset_t, which is fine on 32 bit, but casts away the
pending RT signals on 64 bit.
Fix this by changing the return type of sig_send to sigset_t, so
as not to narrow down the sigset when returning from handling
__SIGPENDING. Make sure to cast correctly in all invocations
of sig_send.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Have sched_getaffinity() interface like glibc's, and provide an
undocumented internal interface __sched_getaffinity_sys() like the Linux
kernel's sched_getaffinity() for benefit of taskset(1).
Martin Storsjö
Corinna Vinschen
Mark Geisert
Takashi Yano
Joel Sherrill
Lavrentiev, Anton
Michael Haubenwallner
Corinna Vinschen
Ken Brown