- Currently, transfer input is triggered even if the stdin of native
app is not a pseudo console. With this patch it is triggered only
if the stdin is a pseudo console.
- If two non-cygwin apps are started simultaneously, attaching to
pseudo console sometimes fails. This is because the second app
trys to attach to the process not started yet. This patch avoids
the issue by attaching to the stub process rather than the other
non-cygwin app.
- Perhaps current code misunderstand meaning of the IGNBRK. As far
as I investigated, IGNBRK is concerned with break signal in serial
port but there is no evidence that it has effect to ignore Ctrl-C.
This patch stops ignoring Ctrl-C by IGNBRK for non-cygwin apps.
This reverts commit 532b91d24e9496c7988b2b1dda7fc0e8b161f782.
It turned out that this patch has undesired side effects. To wit, if a
newer, post-uname_x executable was linked against or loading an older,
pre-uname_x DLL, and this DLL called uname. This call would jump into
the old uname with the old struct utsname as parameter, but given the
newer executable it would get redirected to uname_x. uname_x in turn
would overwrite stack memory it should leave well alone, given it
expects the newer, larger struct utsname.
For the entire discussion see the thread starting at
https://cygwin.com/pipermail/cygwin/2021-February/247870.html
and continuing in March at
https://cygwin.com/pipermail/cygwin/2021-March/247930.html
For a description where we're coming from, see
https://cygwin.com/pipermail/cygwin/2021-March/247959.html
While we *could* make the scenario in question work by patching dlsym,
the problem would actually be the same, just for dynamic loading. In
the end, we're missing the information, which Cygwin version has been
used when building DLLs.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This is not yet complete. Something has to be done to allow
deserialize to recover the fifo name. Perhaps serialize needs to
create a conv_handle?
Untested.
- If two non-cygwin apps are started simultaneously and this is the
first execution of non-cygwin apps in the pty, these occasionally
hang up. The cause is the race issue between term_has_pcon_cap(),
reset_switch_to_pcon() and setup_pseudoconsole(). This patch fixes
the issue.
linkat(olddirfd, oldpath, oldname, newdirfd, newname, AT_EMPTY_PATH)
is supposed to create a link to the file referenced by olddirfd if
oldname is the empty string. Currently this is done via the /proc
filesystem by converting the call to
linkat(AT_FDCWD, "/proc/self/fd/<olddirfd>", newdirfd, newname,
AT_SYMLINK_FOLLOW),
which ultimately leads to a call to the appropriate fhandler's link
method. Simplify this by using cygheap_fdget to obtain the fhandler
directly.
If linkat(2) is called with AT_EMPTY_PATH on an AF_LOCAL or
AF_UNIX socket that is not a socket file, the current code calls
fhandler_disk_file::link in most cases. The latter expects to be
operating on a disk file and uses the socket's io_handle, which
is not a file handle.
Fix this by calling fhandler_disk_file::link only if the
fhandler_socket object is a file (determined by testing
dev().isfs()).
Also fix the case of a socket file opened with O_PATH by setting
the fhandler_disk_file's io_handle.
If facl(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::facl in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::facl only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
If fchown(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchown in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fchown only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
If fchmod(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fhandler_disk_file::fchmod in most
cases. The latter expects to be operating on a disk file and uses the
socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fchmod only if the
fhandler_socket object is a file (determined by testing dev().isfs()).
If fstatvfs(2) is called on an AF_LOCAL or AF_UNIX socket that is not
a socket file, the current code calls fhandler_disk_file::fstatvfs in
most cases. The latter expects to be operating on a disk file and
uses the socket's io_handle, which is not a file handle.
Fix this by calling fhandler_disk_file::fstatvfs only if the
fhandler_socket object is a socket file (determined by testing
dev().isfs()).
If fstat(2) is called on an AF_LOCAL or AF_UNIX socket that is not a
socket file, the current code calls fstat_fs. The latter expects to
be operating on a disk file and uses the socket's io_handle, which is
not a file handle.
Fix this by calling fstat_fs only if the fhandler_socket object is a
file (determined by testing dev().isfs()).
This is in the spirit of the Linux requirement that file operations
like fchmod(2), fchown(2), and fgetxattr(2) fail with EBADF on files
opened with O_PATH.
Hi:
RISC-V has added big-endian support recently, which require config.*
stuff update, and we'll send further patch for fix big-endian build,
so I believe this fundamental change should upstream first.
Import upstream 2021-01-25.
Upstream sha1 6faca61810d335c7837f320733fe8e15a1431fc2
- After commit 253352e796ff9ec9a447e5375f5bc3e2b92b5293, mc (midnight
commander) crashes with segfault if the shell is bash. This is due
to NULL pointer access in read(). This patch fixes the issue.
Addresses::
https://cygwin.com/pipermail/cygwin/2021-February/247870.html
When a FIFO is opened, syscalls.cc:open always calls fstat on the
newly-created fhandler_fifo. This results from a call to
device_access_denied.
To speed-up this fstat call, and therefore the open(2) call, use
PC_KEEP_HANDLE when the fhandler is created. The resulting
conv_handle is retained until after the fstat call if the fhandler is
a FIFO; otherwise, it is closed immediately.
Previously, the call to get_file_attribute for FIFOs set the first
argument to NULL instead of the handle h returned by get_stat_handle,
thereby forcing the file to be opened for fetching the security
descriptor in get_file_sd(). This was done because h might have been
a pipe handle rather than a file handle, and its permissions would not
necessarily reflect those of the file.
That situation can no longer occur with the new fhandler_fifo::fstat
introduced in the previous commit.
Previously fstat on a FIFO would call fhandler_base::fstat.
The latter is not appropriate if fhandler_fifo::open has already been
called (and O_PATH is not set), for the following reason. If a FIFO
has been opened as a writer or duplexer, then it has an io_handle that
is a pipe handle rather than a file handle. fhandler_base::fstat will
use this handle and potentially return incorrect results. If the FIFO
has been opened as a reader, then it has no io_handle, and a call to
fhandler_base::fstat will lead to a call to fhandler_base::open.
Opening the fhandler a second time can change it in undesired ways;
for example, it can modify the flags and status_flags.
The new fhandler_fifo::fstat avoids these problems by creating an
fhandler_disk_file and calling its fstat method in case
fhandler_fifo::open has already been called and O_PATH is not set.
Consider this case:
- Cygwin installed in C:\cygwin64
- mklink /j D:\cygwin64 C:\cygwin64
- create testcase calling
realpath("/", result);
printf ("%s\n", result);
- start cmd
>C:\cygwin64\bin\bash -lc <path-to-testcase>
/
>D\cygwin64\bin\bash -lc <path-to-testcase>
/cygdrive/c/cygwin64
This scenario circumventing the mount point handling which is automated
in terms of /, depending on the path returned from GetModuleFileNameW
for the Cygwin DLL. When calling D:\cygwin64\bin\bash the dir returned
from GetModuleFileNameW is D:\cygwin64\bin, thus root is D:\cygwin64.
However, junctions are treated as symlinks in Cygwin which explains why
the path gets converted to a cygdrive path.
Fix this by calling GetFinalPathNameByHandleW on the result from
GetModuleFileNameW to get the correct root path, even if accessed via
a junction point.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This only affects the very seldom bordercase of apps calling setmode(fd,
0) on fhandlers not calling fhandler_base::set_open_status(). All
fhandlers not calling set_open_status() are binary mode only, but the
way reset_to_open_binmode worked, calling setmode(fd, 0) would have
"reset" their open flags to O_TEXT accidentally.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- If ENABLE_LINE_INPUT is set, Ctrl-S is handled by Windows if the
OS is Windows 7. This conflicts with Ctrl-S handling in cygwin
console code. This patch unsets ENABLE_LINE_INPUT flag in cygwin
and set it when native app is executed.
- If ENABLE_VIRTUAL_TERMINAL_INPUT is not set, changing window height
does not generate WINDOW_BUFFER_SIZE_EVENT. This happens if console
is in the legacy mode. Therefore, with this patch, the windows size
is checked every time in cons_master_thread() if the cosole is in
the legacy mode.
Linux 5.11 💕 Valentine's Day Edition 💕 added features and changes:
add Intel 0x00000007 EDX:23 avx512_fp16 and 0x00000007:1 EAX:4 avx_vnni;
group scattered AMD 0x8000001f EAX Secure Mem/Encrypted Virt features at end:
0 sme, 1 sev, 3 sev_es (more to come not yet displayed)
Without this, for a bare-iron/simulator target such as cris-elf,
you'll see, at newlib build time:
/x/gccobj/./gcc/xgcc -B/x/gccobj/./gcc/ <many options elided> -c -o lib_a-aligned_alloc.o \
`test -f 'aligned_alloc.c' || echo '/y/newlib/libc/stdlib/'`aligned_alloc.c
/y/newlib/libc/stdlib/aligned_alloc.c: In function 'aligned_alloc':
/y/newlib/libc/stdlib/aligned_alloc.c:35:10: warning: implicit declaration of function \
'_memalign_r' [-Wimplicit-function-declaration]
35 | return _memalign_r (_REENT, align, size);
| ^~~~~~~~~~~
- Currently, Ctrl-Z, Ctrl-\ and SIGWINCH does not work in console
if the process does not call read() or select(). This is because
these are processed in process_input_message() which is called
from read() or select(). This is a long standing issue of console.
Addresses:
https://cygwin.com/pipermail/cygwin/2020-May/244898.htmlhttps://cygwin.com/pipermail/cygwin/2021-February/247779.html
With this patch, new thread which handles only input signals is
introduced so that Crtl-Z, etc. work without calling read() or
select(). Ctrl-S and Ctrl-Q are also handled in this thread.
