On Tue, 4 Feb 2025, Roland Mainz via Cygwin wrote:
> it seems that Cygwin does not support |IO_REPARSE_TAG_MOUNTPOINT| for
> "remote" filesystems:
> snip
> 2582/* Don't handle junctions on remote filesystems as
> symlinks. This type
> 2583 of reparse point is handl
I sent this patch in June
(https://cygwin.com/pipermail/cygwin-patches/2024q2/012712.html), and I
recently remembered I hadn't heard anything about it.
On Tue, 4 Jun 2024, Jeremy Drake via Cygwin-patches wrote:
> In order for these formats to be machine-parseable, characters
This code was duplicated between the lnk symlink type and the native
symlink type.
Signed-off-by: Jeremy Drake
---
winsup/cygwin/path.cc | 62 +++
1 file changed, 28 insertions(+), 34 deletions(-)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
This code was duplicated between the lnk symlink type and the native
symlink type.
Signed-off-by: Jeremy Drake
---
I have been working on cleaning up msys2's "deepcopy" symlink mode code
and noticed it was doing the same thing in a different way. I copy-pasted
the code from the lnk path, then f
On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> Personally, I personally prefer releasing 3.5.6 ASAP.
Is this the plan, now that the hangs seem to be resolved? (Maybe after
additional confirmation/testing?)
--
Problem reports: https://cygwin.com/problems.html
FAQ: h
On Tue, 21 Jan 2025, Jeremy Drake via Cygwin wrote:
> I did not see this happen with ruby 3.3.7, or when building with -j1.
Sorry, spoke too soon, I did see this immediately with 3.3.7 as well.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.
I've been trying to track down why ruby 3.4.1 is failing to build for
msys2. I've now confirmed that this same issue reproduces with
upstream Cygwin 3.5.4 and 3.6.0-0.335.gb879cd1661ad, so I thought I'd
bring it up here:
when building ruby with a high -j value (I'm doing make -j21), I get
errors
dscho hooked me up with a workflow to run Git for Windows' test suite on
an msys2-runtime pull request's CI artifacts. With this patch and the
three you pushed (reverting the v2 patch we had applied already, and
applying the two from the cygwin-3_5-branch), the test suite no longer
hangs.
On Mon,
Not important, but
On Tue, 21 Jan 2025, Takashi Yano wrote:
> + if (!_my_tls.locals.cw_timer_inuse)
> + _my_tls.locals.cw_timer_inuse = true;
Couldn't you leave the if out?
On Tue, 21 Jan 2025, Takashi Yano wrote:
> diff --git a/winsup/cygwin/cygwait.cc b/winsup/cygwin/cygwait.cc
> index 80c0e971c..8613638f6 100644
> --- a/winsup/cygwin/cygwait.cc
> +++ b/winsup/cygwin/cygwait.cc
> @@ -58,16 +58,22 @@ cygwait (HANDLE object, PLARGE_INTEGER timeout, unsigned
> mask)
On Sun, 19 Jan 2025, Takashi Yano wrote:
> Thanks for pointing out this. You are right if othre threads may
> set current_sig to non-zero value. Current cygwin sets current_sig
> to non-zero only in
> _cygtls::interrupt_setup()
> and
> _cygtls::handle_SIGCONT()
> both are called from sigpacket::pr
On Sat, 18 Jan 2025, Takashi Yano wrote:
> While debugging this problem, I encountered another hang issue,
> which is fixed by:
> 0001-Cygwin-signal-Avoid-frequent-tls-lock-unlock-for-SIG.patch
I'm concerned about this patch. There's a window where current_sig could
be changed after exiting the
On Sat, 18 Jan 2025, Takashi Yano wrote:
> Jeremy,
> could you please apply the attached patches:
> 0001-Cygwin-signal-Avoid-frequent-tls-lock-unlock-for-SIG.patch
> 0003-Cygwin-signal-Do-not-handle-signal-when-__SIGFLUSHFA.patch
> against cygwin-3_5-branch and test if these fix the issue?
I open
On Wed, 15 Jan 2025, Brian Inglis wrote:
> +<<< HEAD
> isastream
> +===
> +kill_dependency (not available in "stdatomic.h" header)
> +>>> 5888275d7f48 (Cygwin: winsup/doc/posix.xml: SUS V5 POSIX 2024 move
> or remove dropped entries)
Conflict added here, removed in
On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote:
> Hi Michael,
>
> Personally, I personally prefer releasing 3.5.6 ASAP. However, we
> are not sure that we have already fixed all the major problems in
> 3.5.5.
>
> Can you please test latest cygwin 3.6.0 (TEST) whether the your
> CI issue still
On Thu, 9 Jan 2025, Corinna Vinschen wrote:
> Hi Jeremy,
>
> Can you perhaps bisect 3.5.5 to tell us which signal-related patch
> exactly has introduced this specific hang? It may give us a clue.
I believe Johannes was planning to do this, after holidays/vacation. It
seems that Git for Windows'
On Thu, 9 Jan 2025, Takashi Yano wrote:
> On Wed, 8 Jan 2025 16:48:41 +0100
> Corinna Vinschen wrote:
> > Does this patch fix Bruno's bash issue as well?
>
> I'm not sure because it is not reproducible as he said.
> I also could not reproduce that.
>
> However, at least this fixes the issue that J
There are known (and as yet unknown) hang issues with cygwin 3.5.5, the
known being in signal handling. You might try with cygwin 3.5.4 to see if
your hang issues go away. That might help elimiate python as the culprit.
On Fri, 3 Jan 2025, Michael Cook via Cygwin wrote:
> The hangs I've looked
On Wed, 25 Dec 2024, Jeremy Drake via Cygwin wrote:
> We ran into hang issues with libtool linking imagemagick in msys2, using
> version based on 3.5.5, 3 times in a row on our ARM64 runner. We applied
> your v2 patch to our 3.5.5 branch (with the change of current_sig to sig),
> a
On Wed, 25 Dec 2024, Takashi Yano via Cygwin wrote:
> On Tue, 24 Dec 2024 22:34:44 +0100
> Bruno Haible wrote:
> > This is not reproducible, but here's the report anyway:
> >
> > I upgraded a Windows 10 system from Cygwin 3.5.3 to 3.5.5 today.
> > Then ran the configure script of a tarball (*), an
On Fri, 29 Nov 2024, Corinna Vinschen wrote:
> On Nov 27 14:04, Jeremy Drake via Cygwin-patches wrote:
> > https://gist.github.com/jeremyd2019/aa167df0a0ae422fa6ebaea5b60c80c9
>
> Nice! If you feel confident to merge something like this into
> Cygwin, feel free to send patc
> > > On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> > >
> > > > Btw...
> > > >
> > > > We're doing this because nobody being able to debug ARM64 assembler came
> > > > up with a piece of code checking the ntdll assembler code to find the
> > > > address of the fast_cwd_pointer on ARM64.
> > > >
>
From: Jeremy Drake
If the Cygwin dll's architecture is different from the host system's
architecture, append an additional tag that indicates the host system
architecture (the Cygwin dll's architecture is already indicated in
machine).
Signed-off-by: Jeremy Drake
---
v2: get rid of hardcoded st
From: Jeremy Drake
This was already used in the FAST_CWD check, and could be used in a
couple other places.
I found the "emulated"/process value returned from the function largely
useless, so I did not cache it. It is useless because, as the docs say,
it is set to IMAGE_FILE_MACHINE_UNKNOWN (0)
On Wed, 27 Nov 2024, Corinna Vinschen wrote:
> I'm not opposed to a switch statement consisting of an
> IMAGE_FILE_MACHINE_ARM64 case and a default case adding "-???" or
> something. Chances are so extremly slim that we'll ever see another
> CPU emulated on x86_64, we can always add a case for th
On Tue, 26 Nov 2024, Jeremy Drake via Cygwin-patches wrote:
> On Tue, 26 Nov 2024, Corinna Vinschen wrote:
>
> > Btw...
> >
> > We're doing this because nobody being able to debug ARM64 assembler came
> > up with a piece of code checking the ntdll assembler
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> Btw...
>
> We're doing this because nobody being able to debug ARM64 assembler came
> up with a piece of code checking the ntdll assembler code to find the
> address of the fast_cwd_pointer on ARM64.
>
> You seem to have the knowledge and the means to
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> On Nov 25 11:24, Jeremy Drake via Cygwin-patches wrote:
> > + switch (wincap.host_machine ())
> > + {
> > + case IMAGE_FILE_MACHINE_AMD64:
> > + n = stpcpy (buf, "-x64") - b
On Tue, 26 Nov 2024, Corinna Vinschen wrote:
> On Nov 25 11:21, Jeremy Drake via Cygwin-patches wrote:
> > +extern const IMAGE_DOS_HEADER
> > +dosheader __asm__ ("__image_base__");
>
> On second thought, shouldn't we just use GetModuleHandle ("cygwin1.
From: Jeremy Drake
If the Cygwin dll's architecture is different from the host system's
architecture, append an additional tag that indicates the host system
architecture (the Cygwin dll's architecture is already indicated in
machine).
Signed-off-by: Jeremy Drake
---
v2: get rid of hardcoded st
From: Jeremy Drake
This was already used in the FAST_CWD check, and could be used in a
couple other places.
I found the "emulated"/process value returned from the function largely
useless, so I did not cache it. It is useless because, as the docs say,
it is set to IMAGE_FILE_MACHINE_UNKNOWN (0)
On Sat, 23 Nov 2024, Cedric Blancher via Cygwin wrote:
> Good afternoon!
>
> Does Cygwin do a silly rename if a Cygwin file is open but gets
> /bin/rm at the same time?
Yes! See function try_to_bin in winsup/cygwin/syscalls.cc:
/* Create unique filename. Start with a dot, followed by "cyg
From: Jeremy Drake
It appears this is causing hangs on native x86_64 in similar scenarios
as the hangs on ARM64, because `CancelSynchronousIo` is returning `TRUE`
but not canceling the `ReadFile` call as expected.
Addresses:
https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-24914
On Fri, 22 Nov 2024, Corinna Vinschen wrote:
> > wait_thread is happily waiting in ReadFile, while the main thread is
> > hanging in ForceCloseHandle1 (close_h, rd_proc_pipe);.
>
> which is one of the great annoyances of Windows. CloseHandle
> on a pipe should never hang, but... well...
Yeah
On Fri, 22 Nov 2024, Corinna Vinschen wrote:
> On Nov 21 11:42, Jeremy Drake via Cygwin-patches wrote:
> > Note the elif defined (__i386__) case won't compile because it references
> > the no-longer-present `wow64` value. This was written and tested against
> > 3.3.6, a
On Thu, 21 Nov 2024, Jeremy Drake via Cygwin-patches wrote:
> @@ -38,6 +81,7 @@ uname_x (struct utsname *name)
>/* sysname */
>__small_sprintf (name->sysname, "CYGWIN_%s-%u",
> wincap.osname (), wincap.build_number ());
> +
On Wed, 20 Nov 2024, Jeremy Drake via Cygwin-patches wrote:
> On Wed, 20 Nov 2024, Corinna Vinschen wrote:
>
> > Patch pushed.
>
> Thanks, folks on ARM64 will be very happy to see that deadlock gone.
> MSYS2 already made a release based on v2 of the patch, and Git for Wind
This was already used in the FAST_CWD check, and could be used in a
couple other places.
I found the "emulated"/process value returned from the function largely
useless, so I did not cache it. It is useless because, as the docs say,
it is set to IMAGE_FILE_MACHINE_UNKNOWN (0) if the process is no
If the Cygwin dll's architecture is different from the host system's
architecture, append an additional tag that indicates the host system
architecture (the Cygwin dll's architecture is already indicated in
machine).
---
You may well want me to remove some cases from the switch ;)
winsup/cygwin/u
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> IMHO:
>
> if (IsWow64Process2 (GetCurrentProcess (), &emulated, &hosted))
> && emulated != IMAGE_FILE_MACHINE_UNKNOWN)
> if (hosted == IMAGE_FILE_MACHINE_AMD64)
> strcat (sysname, "-WOW64");
> else if (hosted == IMAGE_
On Thu, 21 Nov 2024, Corinna Vinschen via Cygwin wrote:
> > i686x86_64 -WOW64-x64 (or omit arch to match existing?)
>
> Just -WOW64
>
> For backward compat and it's a sole representative of an intel-intel
> emulation anyway. I think we may safely ignore "WOW"
>
> > i686ARM64 -W
On Wed, 20 Nov 2024, Jeremy Drake via Cygwin wrote:
> CygwinHostSuffix
> Not worth worrying about:
> ARM ARM64 -WOW64-ARM (?)
Oops, this should have been -WOW64-ARM64 since the host is ARM64. But
like I said, this case would never happen anyway.
--
Problem reports:
I mentioned this briefly on cygwin-patches during the review of the fix
for a deadlock when running under emulation on ARM64 hosts, but I wanted
to discuss it more thoroughly here now that that is merged.
It seems like it would be useful, perhaps for stats tracking purposes like
MSYS2 does [1], to
On Wed, 20 Nov 2024, Corinna Vinschen wrote:
> Patch pushed.
Thanks, folks on ARM64 will be very happy to see that deadlock gone.
MSYS2 already made a release based on v2 of the patch, and Git for Windows
at least merged that version of the patch too, and is looking forward to
making a release wi
On Tue, 19 Nov 2024, Corinna Vinschen wrote:
> On Nov 19 11:06, Jeremy Drake via Cygwin-patches wrote:
> > (I searched for other callers of terminate_thread after this, and the only
> > one left without CancelSynchronousIo is in ldap.cc and I'm pretty sure
> > th
From: Jeremy Drake
This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.
A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.
It would s
On Tue, 19 Nov 2024, Corinna Vinschen wrote:
> On Nov 18 10:10, Jeremy Drake via Cygwin-patches wrote:
> > On Mon, 18 Nov 2024, Corinna Vinschen wrote:
> >
> > > Neat, but if this only affects the ARM64 emulation, shouldn't this only
> >
On Mon, 18 Nov 2024, Corinna Vinschen wrote:
> Neat, but if this only affects the ARM64 emulation, shouldn't this only
> be called under wincap.cpu_arch() == PROCESSOR_ARCHITECTURE_AMD64?
Wouldn't this always be true though? (Except that I backported this to
3.3.6 for i686 support, where I'd hav
From: Jeremy Drake
This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.
A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.
It would s
On Tue, 12 Nov 2024, Jeremy Drake via Cygwin-patches wrote:
> diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc
> index 81b6c31695..360bdac232 100644
> --- a/winsup/cygwin/sigproc.cc
> +++ b/winsup/cygwin/sigproc.cc
> @@ -410,7 +410,8 @@ proc_terminate ()
>
On Wed, 13 Nov 2024, Johannes Schindelin wrote:
> Hi Jeremy,
>
> Excellent work! Thank you for your impressive tenacity to stick with this
> problem. I built an MSYS2 runtime with the fix in
> https://github.com/git-for-windows/msys2-runtime/pull/73, and then started
> your reproducer from
> https
From: Jeremy Drake
This addresses an extremely difficult to debug deadlock when running
under emulation on ARM64.
A relatively easy way to trigger this bug is to call `fork()`, then within the
child process immediately call another `fork()` and then `exit()` the
intermediate process.
It would s
On Sat, 28 Sep 2024, Mark Liam Brown via Cygwin wrote:
> On Tue, Sep 17, 2024 at 12:49 PM Mark Liam Brown
> wrote:
> >
> > Greetings!
> >
> > Are there Cygwin 3.6 x86/32bit builds?
> > We're on Windows 10/ARM64, and as Cygwin does not support ARM64 yet
> > the only other option is to use the x86
On Thu, 19 Sep 2024, Brian Inglis via Cygwin wrote:
> On 2024-09-19 07:27, Christian Franke via Cygwin wrote:
> >
> >
> > Yes, but Cygwin does not provide consistent forward/reverse UTF-8 <-> UTF-16
> > mappings.
>
> Surrogates halves are invalid for UTF-8 encoding; they should be first be
> encod
On Sun, 4 Aug 2024, Jeremy Drake via Cygwin wrote:
> TASKKILL /F /IM cygwin1.dll
> to kill them
Oops, make that
TASKKILL /F /FI "MODULES eq cygwin1.dll"
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentati
On Sun, 4 Aug 2024, Brian Inglis via Cygwin wrote:
> Most such problems happen because something has been running and not yet
> terminated before running Cygwin Setup, or Windows Scheduled Tasks running
> Cygwin processes while running Cygwin Setup.
>
> I start Task Manager, tab Details, sort by I
Replying to cygwin@cygwin.com list due to determination that this thread
was incorrectly sent to cygwin-developers. I apologize for the
inconvenience.
On Tue, 21 May 2024, Jeremy Drake wrote:
> On Mon, 20 May 2024, Jeremy Drake wrote:
>
> > Today, I was attempting to look at the TerminateThread
On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
> On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
>
> > Eliot Moss replied to me privately, and I confirmed as well, that this
> > does not occur with Cygwin 3.5.1-1. So this appears to be a regression
> > in 3.5
On Fri, 14 Jun 2024, Jeremy Drake via Cygwin wrote:
> Eliot Moss replied to me privately, and I confirmed as well, that this
> does not occur with Cygwin 3.5.1-1. So this appears to be a regression
> in 3.5.3.
It also does not occur in 3.6.0-0.81 or 3.6.0-0-0.115, so perhaps this wa
On Thu, 13 Jun 2024, Jeremy Drake via Cygwin wrote:
> Thankfully, this can be simply reproduced with the following two bash
> commands (on cygwin 3.5.3):
>
> mkdir -p foo/$'\uD800'
> rm -rf foo
Eliot Moss replied to me privately, and I confirmed as well, that this
d
On Thu, 13 Jun 2024, Brian Inglis via Cygwin wrote:
> These reserved surrogate values should probably either be blocked, or encoded
> at
> the file system interface layer so they can be round tripped, like the Windows
> reserved characters, in the BMP or SMP PUAs.
>
> Reserved surrogate ranges are
Backstory: rust's test suite makes an oddly-named directory as part of a
test:
https://github.com/rust-lang/rust/blob/921645c737f1d6d107a0a10ca5ee129d364dcd7a/tests/run-make/non-unicode-in-incremental-dir/rmake.rs
When trying to clean up after a rust build/test with rm -rf, it results in
a "Direct
On Wed, 5 Jun 2024, Ken Takata via Cygwin wrote:
> > I've updated keychain.cygport for the latest version of keychain.
> > Please find the attached file.
> > Could you include this in the cygwin package repository and release a new
> > version?
>
> How can we proceed to update keychain to 2.8.5?
In order for these formats to be machine-parseable, characters used as
delimiters must be escaped. Linux escapes space, tab, newline,
backslash, and hash (because code that parses mounts/mtab and fstab
would handle comments) using octal escapes. Replicate that behavior
here.
Addresses: https://c
In order for these formats to be machine-parseable, characters used as
delimiters must be escaped. Linux escapes space, newline, backslash,
and hash (because code that parses mounts/mtab and fstab would handle
comments) using octal escapes. Replicate that behavior here.
Addresses: https://cygwin
On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote:
> /proc/self/mounts and /proc/self/mountinfo use octal escapes for ' ' and
> \n (I was rather surprised they didn't escape \r also, but I guess they
> don't have to because only ' ' and \n are used as del
Steps to reproduce:
$ mkdir /$'My New\r\nFolder'
$ mount c: /$'My New\r\nFolder'
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary,auto)
C: on /My New
Folder type ntfs (binary,user)
$ cat /proc/self/m
I'm not necessarily sure that the subject is clear enough, so I want to be
explicit that I'm talking about files (or I guess potentially directories,
though I've never seen that) generated by the `try_to_bin` function in
winsup/cygwin/syscalls.cc. Specifically, you can generate one with this
simpl
On Sat, 1 Jun 2024, Takashi Yano wrote:
> + const int destroyed = INT_MIN >> 1;/* 0b1100 */
I thought whether or not right shifting a negative number sign-extends was
undefined in the C/C++ standards?
On Tue, 28 May 2024, Jeremy Drake via Cygwin-patches wrote:
> @@ -53,6 +53,7 @@ cygcheck_LDADD = -lz -lwininet -lshlwapi -lpsapi -lntdll
Oops, I accidentally generated this patch against msys2-3.5.3 branch,
rather than cygwin master like the last one. The only difference is the
line numb
If ldd is run against a DLL which links to the Cygwin DLL, ldh will end
up loading the Cygwin DLL dynamically, much like cygcheck or strace.
Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
Signed-off-by
On Tue, 28 May 2024, Takashi Yano wrote:
> On Mon, 27 May 2024 22:36:07 -0700 (PDT)
> Jeremy Drake wrote:
> > If ldd is run against a DLL or EXE which links to the Cygwin DLL, ldh
> > will end up loading the Cygwin DLL dynamically, much like cygcheck or
> > strace.
>
> IIUC, ldh is not used for EX
If ldd is run against a DLL or EXE which links to the Cygwin DLL, ldh
will end up loading the Cygwin DLL dynamically, much like cygcheck or
strace.
Addresses: https://cygwin.com/pipermail/cygwin/2024-May/255991.html
Fixes: 60675f1a7eb2 ("Cygwin: decouple shared mem regions from Cygwin DLL")
Signed
On Fri, 24 May 2024, Jeremy Drake wrote:
> On Fri, 24 May 2024, Jeremy Drake wrote:
>
> > Looking at !address, it seems Windows put the PEB, TEBs, and stacks in the
> > area where the cygheap should be. Way to go, ASLR :P
>
> I think the fix for this would be to add -Wl,--disable-high-entropy-va
On Fri, 24 May 2024, Jeremy Drake wrote:
> Looking at !address, it seems Windows put the PEB, TEBs, and stacks in the
> area where the cygheap should be. Way to go, ASLR :P
I think the fix for this would be to add -Wl,--disable-high-entropy-va to
ldh_LDFLAGS, as was done for strace and cygcheck
On Fri, 24 May 2024, Jeremy Drake wrote:
> On Fri, 24 May 2024, Jeremy Drake wrote:
>
> > Windbg reports that ldh.exe is already being debugged. I was able to do a
> > "non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
> > to deal with the split debug symbols (gnulink?).
On Fri, 24 May 2024, Jeremy Drake wrote:
> Windbg reports that ldh.exe is already being debugged. I was able to do a
> "non-invasive" attach to ldh.exe in windbg, but it doesn't seem to be able
> to deal with the split debug symbols (gnulink?). I don't know if gdb can
> do a non-invasive attach
On Sat, 25 May 2024, Takashi Yano wrote:
> On Fri, 24 May 2024 14:46:40 -0700 (PDT)
> Jeremy Drake wrote:
> > > Thanks for the report. However, I cannot reproduce the issue.
> > > If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> > > bug but a windows bug.
> > >
> > > By
On Sat, 25 May 2024, Takashi Yano wrote:
> Thanks for the report. However, I cannot reproduce the issue.
> If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> bug but a windows bug.
>
> By any chance, is the number of processes that attach to the same pty more
> than 32768
Seen on msys2, but doesn't seem specific to it.
Frequently, when running ldd in a loop, it will hang. I managed to get a
backtrace from gdb with symbols:
(gdb) bt
#0 0x7ffecea0fa34 in ntdll!ZwDeviceIoControlFile ()
from /c/Windows/SYSTEM32/ntdll.dll
#1 0x7ffecbead7a9 in KERNELBASE!G
On Mon, 20 May 2024, Jeremy Drake wrote:
> Today, I was attempting to look at the TerminateThread situation. The
> call in question comes from the attempt to terminate the wait_thread of a
> chld_procs entry. I noticed elsewhere in cygwin code (flock.cc) that
> CancelSynchronousIo was being call
On Wed, 8 May 2024, Jeremy Drake wrote:
> (this is the same issue discussed in
> https://cygwin.com/pipermail/cygwin-patches/2024q1/012621.html)
>
> On MSYS2, running on Windows on ARM64 only, we've been plagued by issues
> with processes hanging up. Usually pacman, when it is trying to validate
(this is the same issue discussed in
https://cygwin.com/pipermail/cygwin-patches/2024q1/012621.html)
On MSYS2, running on Windows on ARM64 only, we've been plagued by issues
with processes hanging up. Usually pacman, when it is trying to validate
signatures with gpgme. When a process is hung in
On Tue, 20 Feb 2024, Corinna Vinschen wrote:
> On Feb 19 21:41, Jeremy Drake via Cygwin wrote:
> > 1) is there actually a good reason that _cygheap_start is in the .rsrc and
> > not the .cygheap section?
>
> As you know we got rid of this way to define the cygheap, but
>
This is probably the right thing to do, but breaks building msys2-runtime
(read: cygwin) 3.3, because the _cygheap_start symbol is actually in the
.rsrc section and code very early attempts to memset _cygheap_start.
Couple of questions:
1) is there actually a good reason that _cygheap_start is in
Thanks for taking the time to write this up, this issue has been bugging
me for years... (see also:
https://cygwin.com/pipermail/cygwin-patches/2021q4/011638.html)
On Sat, 3 Feb 2024, Johannes Schindelin wrote:
> Concretely, the hangs occur typically when some `pacman` process (a
> package manage
On Fri, 2 Feb 2024, Corinna Vinschen wrote:
> On Feb 2 09:43, David Allsopp via Cygwin wrote:
> > However, this patch came from MSYS2, and subsequently they seem to
> > have found it problematic for the same reason as me
> > (https://github.com/msys2/msys2-runtime/pull/18#issuecomment-810897624)
On Tue, 27 Jun 2023, Johannes Schindelin wrote:
> In 4b8222983f (Cygwin: fix errno values set by readlinkat, 2023-04-18)
> the code of `readlinkat()` was adjusted to align the `errno` with Linux'
> behavior.
>
> I noticed this issue when one of my workflows failed consistently
> while
On Wed, 19 Apr 2023, Brian Inglis wrote:
> As 32 bit Windows systems are no longer getting security updates,
> recommendations for similar legacy systems include running them in VMs with
> access to update executables and libraries blocked.
There is a 32-bit variant of Windows 10; Windows 10 is s
On Sat, 31 Dec 2022, 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:
On Fri, 18 Nov 2022, Johannes Schindelin wrote:
> Hi Corinna,
>
> On Mon, 24 Oct 2022, Corinna Vinschen wrote:
>
> > However, two points:
> >
> > - I'm wondering if the patch (both of yours) doesn't actually just cover
> > a problem in child_info_spawn::worker(). Different runpath values,
> >
On Thu, 3 Nov 2022, Jon Turney wrote:
> gdb supports 'set disable-randomization off' on Windows since [1]
> (included in gdb 13).
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=bcb9251f029da8dcf360a4f5acfa3b4211c87bb0;hp=8fea1a81c7d9279a6f91e49ebacfb61e0f8ce008
Is it really *di
On Mon, 11 Apr 2022, Alexey Izbyshev wrote:
> Yes, sshd is running as a service, but I'm not sure that patch is relevant. In
> my case, the problematic pipe that the hanging conhost.exe is waiting on is
> probably created for that specific conhost.exe process within the process tree
> rooted at "m
On Sat, 9 Apr 2022, Alexey Izbyshev wrote:
> I don't have mintty because "make" is run via an SSH session. I suppose
> I should look into sshd in this case?
Sshd wouldn't happen to be running as a service, would it?
https://cygwin.com/pipermail/cygwin-patches/2022q2/011867.html
--
Problem rep
On Tue, 29 Mar 2022, Takashi Yano wrote:
> diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
> index b87160edb..006c7b4bf 100644
> --- a/winsup/cygwin/fhandler.h
> +++ b/winsup/cygwin/fhandler.h
> @@ -1194,6 +1194,7 @@ private:
>HANDLE hdl_cnt_mtx;
>HANDLE query_hdl_proc;
>
On Tue, 29 Mar 2022, Takashi Yano wrote:
> diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
> index fb3d09d84..cd2d3a7ef 100644
> --- a/winsup/cygwin/spawn.cc
> +++ b/winsup/cygwin/spawn.cc
> @@ -645,8 +646,18 @@ child_info_spawn::worker (const char *prog_arg, const
> char *const *arg
On Fri, 25 Mar 2022, Takashi Yano wrote:
> I will submit v3 patch shortly.
I applied your v3 patch to 3.3.4 in
https://github.com/msys2/msys2-runtime/pull/88 and re-ran my test action,
and it worked as expected this time.
I've put out a call to test on the msys2-runtime issue to confirm that it
On Fri, 25 Mar 2022, Takashi Yano wrote:
> I can confirm the sample script hangs indeed if the script is
> running as SYSTEM account. However, in my test, the patch solves
> the issue.
>
> It would be very helpfull if a simple github repository with
> github actions, which can reproduce the issue,
On Tue, 22 Mar 2022, Takashi Yano wrote:
> > Thanks for the report. This is expected problem as mentioned
> > in b531d6b commit message. However, I could not imagin the
> > situation that the service has multiple writer for the pipe
> > and one of them is a non-cygwin app.
> >
> > Question is: Doe
This issue was reported to MSYS2 as a hang when trying to build libxml2 in
a Windows docker container. Another user was able to come up with a
simple reproducer and a reasonable theory as to why it happens. The msys2
issue is https://github.com/msys2/msys2-runtime/issues/77, and I will
quote the
1 - 100 of 150 matches
Mail list logo
