On Mon, 28 Apr 2025, Jeremy Drake via Cygwin wrote:
> I was just describing cygwin_conv_path on a rust issue
> (https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that
> the pointer `to` is not accessed when `size` is 0, but it turns out on
> circa line 4022 in pa
I was just describing cygwin_conv_path on a rust issue
(https://github.com/rust-lang/backtrace-rs/pull/704). I was saying that
the pointer `to` is not accessed when `size` is 0, but it turns out on
circa line 4022 in path.cc
to = (void *) wcpcpy ((wchar_t *) to, ro_u_globalroot.Buffer);
This is
On Sun, 27 Apr 2025, David Christensen wrote:
> On 4/27/25 14:59, Jeremy Drake wrote:
> > On Sun, 27 Apr 2025, Jeremy Drake via Cygwin wrote:
> > > Does sshfs.exe have any exports? Should it?
>
>
> Thank you for the reply.
>
>
> I do not know how to ans
On Sun, 27 Apr 2025, Jeremy Drake via Cygwin wrote:
> On Sun, 27 Apr 2025, David Christensen via Cygwin wrote:
>
> > The procedure entry point cygfuse_report could not be
> > located in the dynamic link library C:\cygwin64\sshfs.exe.
> > -> OK
>
> Does sshfs
I was asked an interesting question on a github issue about rust
backtraces: is there an API in Cygwin to get a list of loaded modules? I
know the info is there in the dlls list, but I don't see an API to get at
it.
The question was in regards to whether rust should be using toolhelp32 on
Cygwin
On Sun, 27 Apr 2025, David Christensen via Cygwin wrote:
> The procedure entry point cygfuse_report could not be
> located in the dynamic link library C:\cygwin64\sshfs.exe.
> -> OK
Does sshfs.exe have any exports? Should it?
(It is legal for an exe to have exports, and for a DLL to reference t
On Sun, 20 Apr 2025, Takashi Yano via Cygwin wrote:
> Is there any other blocker to build Rust for cygwin?
https://github.com/rust-lang/rust/issues/137819
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwi
On Sun, 20 Apr 2025, Takashi Yano via Cygwin wrote:
> On Mon, 24 Mar 2025 14:41:19 +0800
> Yuyi Wang wrote:
> > > I mean it is some kind of cross compiler.
> >
> > Yes. Rustc is a cross compiler powered by LLVM.
> >
> > > ...is it possible to build Rust compiler itself by the cross-compiler?
> >
>
On Mon, 14 Apr 2025, Bruno Haible via Cygwin wrote:
> Especially since this commit modified select.cc, removing a comment
> /* TODO: Buffer really full or non-Cygwin reader? */
> and here we are exactly in that case: a non-Cygwin process reading from
> Cygwin's /dev/null.
That's Cygwin's select
On Fri, 11 Apr 2025, Andrey Repin via Cygwin wrote:
> Though, I'm using takecommand's free runtime (TCC-RT), which has an explicit
> START /ELEVATED command, and I'm using a wrapper for such tasks.
cygutils'
cygstart -a runas /bin/bash ... ?
--
Problem reports: https://cygwin.com/problems.
On Thu, 10 Apr 2025, Corinna Vinschen via Cygwin wrote:
> > It seems glibc takes care of this implicit deregistration in
> > __cxa_finalize, after calling __cxa_atexit functions, it unregisters any
> > at_quick_exit or pthread_atfork callbacks from the DSO being unloaded.
> >
> > https://sourcewar
On Thu, 10 Apr 2025, Takashi Yano via Cygwin wrote:
> On Wed, 9 Apr 2025 16:41:18 -0700 (PDT)
> Jeremy Drake wrote:
> > I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of
> > llvm/clang, we've got something that seems to mostly work for a cygwin
&
On Wed, 9 Apr 2025, Jeremy Drake via Cygwin wrote:
> On Thu, 10 Apr 2025, Kevin Schnitzius via Cygwin wrote:
>
> > On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin
> > wrote:
> >
> > > The recent issue with pthread_atfork handlers remin
On Thu, 10 Apr 2025, Kevin Schnitzius via Cygwin wrote:
> On Wednesday, April 9, 2025 at 06:54:34 PM EDT, Jeremy Drake via Cygwin
> wrote:
>
> > The recent issue with pthread_atfork handlers reminded me of a scenario
> > that I know glibc handles, but it seems that Cygwin
I've been doing some building with cmake 4.0.0 and ninja 1.12.1 (of
llvm/clang, we've got something that seems to mostly work for a cygwin
target), and I'm noticing after updating to 3.6.1 it no longer seems to
cancel the build when I hit Ctrl-C (previously I was still on 3.5 due to
the cmake/ninja
The recent issue with pthread_atfork handlers reminded me of a scenario
that I know glibc handles, but it seems that Cygwin does not. Test case:
== test.c ==
#include
#include
#include
#include
typedef void(*func_type)(void);
int main(void)
{
int wstatus = 0;
func_type func = NULL;
vo
On Sat, 5 Apr 2025, Jon Turney wrote:
> On 05/04/2025 06:28, Jeremy Drake via Cygwin wrote:
> > I just happened to look at dlfcn.cc dladdr function, and I had a question.
> > Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
> > flag? It doesn't
I just happened to look at dlfcn.cc dladdr function, and I had a question.
Should dladdr be using the GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT
flag? It doesn't seem like dladdr should be incrementing the refcount.
--
Problem reports: https://cygwin.com/problems.html
FAQ:
On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:
> On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
> wrote:
> > No, but if we want to *better* support this driver, we need either a
> > patch (preferred) or at least info how to distinguish in
> > fs_info::update(*) between the MSFT d
On Thu, 3 Apr 2025, Takashi Yano via Cygwin wrote:
> It seems that raw_write() is called before returning from
> pthread::atforkchild() in fork::child().
>
> Moving _my_tls.fixup_after_fork() before atforkchild() seems
> to solve the issue.
>
> What about:
> ld_preload ();
> fixup_hooks_after_fork
On Mon, 31 Mar 2025, Christoph Reiter via Cygwin wrote:
> Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a chance of
> that failing, for example like this:
>
> CMake Error: Generator: build tool execution failed, command was:
> /usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.e
On Mon, 31 Mar 2025, Corinna Vinschen via Cygwin wrote:
> On Mar 30 14:02, Jeremy Drake via Cygwin wrote:
> > I kind of think
> > https://github.com/Kitware/CMake/blob/5978c57c20b762a5aeb4b00f31a51a090d670430/Utilities/cmcurl/CMakeLists.txt#L165
> > should match "^(Lin
On Sun, 30 Mar 2025, Jeremy Drake via Cygwin wrote:
> I tried to build cmake 4.0.0 with latest test gcc and cygwin packages, and
> got the following error
>
> /home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c: In
> function ‘weak_random’:
> /home/WDAGUtilityA
I tried to build cmake 4.0.0 with latest test gcc and cygwin packages, and
got the following error
/home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c: In
function ‘weak_random’:
/home/WDAGUtilityAccount/cmake-4.0.0/Utilities/cmcurl/lib/rand.c:124:21:
error: implicit declaration of fu
On Sat, 29 Mar 2025, Soren via Cygwin wrote:
> I'll add a bit more information in hopes that we can still find a fix. This
> Windows 10 laptop goes into "sleep mode" after a couple hours of no
> keyboard or mouse input, and when it does so sshd disconnects any sessions.
>
> Also, I remember hearin
On Tue, 4 Mar 2025, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> Is IO_REPARSE_TAG_LX_SYMLINK supported in Cygwin 3.3?
>
> Ced
Use the Source, Luke
https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/path.cc?h=cygwin-3_3-branch#n2625
(that's the reading part, the making part i
On Fri, 21 Feb 2025, Jeremy Drake via Cygwin wrote:
> I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
> branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
>
> 1. Git for Windows's test suite still passes with that (wh
b,
newline, hash, backslash) are now escaped within records as octal \NNN.
In the below snippet, I only convert to delimited by \0 *after*
unescaping, when spaces or newlines may be present in the entries.
> On Sun, Mar 2, 2025 at 10:57 PM Jeremy Drake via Cygwin
> wrote:
>
> > #
On Sun, 2 Mar 2025, Jeremy Drake via Cygwin wrote:
> > 2) assuming there is not, I want to make a script using only things
> > present in a "base system" to clean them up.
>
> Now that the mount points are escaped and contain the Windows volume roots
> starting
On Mon, 3 Jun 2024, Jeremy Drake via Cygwin wrote:
> 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` fun
On Thu, 27 Feb 2025, Jan Nijtmans via Cygwin wrote:
> Hi all,
>
> I'll try to find time to update this, in the coming weeks. The problem is
> that
> sqlite for cygwin has some cygwin-specific changes, which were never
> accepted upstream. So it's not trivial to do that. An additional problem
> is
On Tue, 25 Feb 2025, Takeshi Nishimura via Cygwin wrote:
> No, it's beegfs.sys you install.
> SMB is not used, it uses its own protocol. If you do a
> FileRemoteProtocolInfo query the protocol field says it's a
> WNNC_NET_RDR2SAMPLE.
Always nice when a driver doesn't change "sample" idenfiers. I
On Tue, 25 Feb 2025, Cedric Blancher via Cygwin wrote:
> WebDAV and BeeGFS are not alone, the Windows ms-nfs41-client and
> ms-nfs42-client ALWAYS (even with default NFSv4.1 port TCP/2049) use
> UNC paths with "@" character, like
> \\stripe02.zebracluster.intra.pasteur.fr@2049\nfs4\disk02\
> OpenT
On Sat, 22 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 21 14:35, Jeremy Drake via Cygwin wrote:
> > 2. This seems to have fixed a severe performance regression in Curl's test
> > suite (https://github.com/curl/curl/pull/16217) that I was recently
> > looking
I rebased msys2's msys2-runtime fork of cygwin on top of cygwin's master
branch, and then rebased git-for-windows' msys2-runtime on top of THAT.
1. Git for Windows's test suite still passes with that (which is nice, it
tended to hang when we did this with 3.5.5).
2. This seems to have fixed a sev
On Thu, 20 Feb 2025, Roland Mainz via Cygwin wrote:
> > > Same happens with dash and ksh93.
>
> And THAT statement is BAD, because it means basic shell functionality
> is broken, affecting dash/bash/ksh93 - reading that IMO means Cygwin
> has a problem in the pipe/fifo code... ;-(
>
> Best way for
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 18 11:19, Jeremy Drake via Cygwin wrote:
> > On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> >
> > > Yep. Are you going to create a patch?
> >
> > I'm not seeing a parti
On Tue, 18 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Yep. Are you going to create a patch?
I'm not seeing a particularly clean way to do this. Bring back
available_drives, mask off bits when we see the corresponding drive root
from dos_drive_mappings, and return those drive letters whose bi
On Tue, 18 Feb 2025, Cedric Blancher via Cygwin wrote:
> Good evening!
>
> Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit:
>
> df -k no longer shows the data of SMB filesystems, e.g. mount points
> N:-Z: are mounted, but df -k shows nothing:
Ugh, do we have to somehow union volume m
On Mon, 17 Feb 2025, Corinna Vinschen wrote:
> The requirements of posix_spawn and their helper functions are so
> that we can't easily fulfill them without doing the fork/exec
> twist.
>
> See https://man7.org/linux/man-pages/man3/posix_spawn.3.html.
> Windows CreateProcess() is not quite the sam
On Mon, 17 Feb 2025, Corinna Vinschen via Cygwin wrote:
> In fact, I can reproduce this occassionally back to 3.5.0 and back to
> OpenSSH 9.7p1. We can't easily try this with older Cygwin versions.
> It's getting increasingly hard to build older Cygwin versions due to
> compiler dependencies and
On Sat, 8 Feb 2025, Corinna Vinschen via Cygwin wrote:
> Go for it. There's already matching logic in fhandler/proc.cc,
> function format_proc_partitions() for the "win-mounts" column
> of /proc/partitions. Probably this can be reused.
Actually closer to the dos_drive_mappings at the end of mou
On Fri, 7 Feb 2025, Roland Mainz via Cygwin wrote:
> Hi!
>
>
>
> [Slightly offtopic, but I am banging my head against this problem most
> of the day]
> What symlink value should |MRxCreate()| return on |STATUS_REPARSE| to
> redirect to another DOS drive or UNC path ? I tried something like
>
On Fri, 7 Feb 2025, Corinna Vinschen via Cygwin wrote:
> On Feb 6 13:31, Jeremy Drake via Cygwin wrote:
> > Now that my patch to escape characters in /proc/mounts has been applied,
> > I'll get back to what I was thinking about back in June. I would like to
> > have a
Now that my patch to escape characters in /proc/mounts has been applied,
I'll get back to what I was thinking about back in June. I would like to
have a way to list Windows volume roots in Cygwin, and it seems to make
sense to me to expose them via getmntent, /proc/mounts, etc. The way I
see this
We were attempting to build util-linux 2.40.2 for MSYS2, based on the
source package of util-linux-2.40.2-2 from Cygwin [1]. We were scratching
our heads as to why it wasn't building tasksel for us, when it did in your
package. I evenutally saw in the cygport that it tests for sys/syscall.h
and w
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
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
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
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 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
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 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 Ter
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?
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 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,-
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 cy
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 dea
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 c
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
>
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 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
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)
> 0005EE2D cygintl-8.dll
> 7FFD41A0 cygwin1.dll
> 0003F9F7 cygiconv-2.dll
> 7FFD51C7 advapi32.dll
> 7FFD51FD msvcrt.dll
> 7FFD525A sechost.dll
> 7FFD5265 RPCRT4.dll
> 7FFD4F3A CRYPTBASE.DLL
> 7FFD5038 bcryptPrimitives.dll
> $
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
Copyright (C) 1996 - 2023 Cygwin Authors
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> kill: not enough arguments
>
Seems like --list and --version are complete subcomman
Thanks Brian and Corinna.
Jeremy
On Sun, Jan 22, 2023, 14:57 Brian Inglis via Cygwin
wrote:
> On 2023-01-22 12:21, Corinna Vinschen via Cygwin wrote:
> > On Jan 21 11:30, Jeremy Hetzler via Cygwin wrote:
> >> First, thank you for many years of Cygwin.
> >>
>
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 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 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
> > > Sorry, I am not subscribed to the list so don't have the message to reply
> > > to for threading purposes
> New developer snapshot is up at https://cygwin.com/snapshots/
> Please test.
This works, and make's "make check" now gets the same results as it does
when built with --disable-posix-s
On Mon, 10 Jan 2022, Jeremy Drake wrote:
> From https://github.com/msys2/MSYS2-packages/issues/2801
>
> MSYS2 recently rebuilt GNU make 4.3, and I found that after rebuilding, it
> broke rather horribly on i686, where any attempt to run a command resulted
> in "Invalid arg
>From https://github.com/msys2/MSYS2-packages/issues/2801
MSYS2 recently rebuilt GNU make 4.3, and I found that after rebuilding, it
broke rather horribly on i686, where any attempt to run a command resulted
in "Invalid argument" errors. Some debugging revealed that rebuilding
make resulted in it
Oops, forgot to send to list.
On Wed, 27 Oct 2021, Takashi Yano wrote:
> On Tue, 26 Oct 2021 22:55:01 +0200
> Corinna Vinschen wrote:
> > We're also planning to drop Support for the 32 bit release of Cygwin in
> > 2022, thus Cygwin 3.4.0 won't come in 32 bit anymore, and the package
> > maintaine
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
On Fri, 28 May 2021, Jeremy Drake wrote:
> On Thu, 27 May 2021, Jeremy Drake wrote:
>
> > > > Treating mapped/subst drives as though they were not symlinks, without
> > > > messing with intermedate symlinks.
> > >
> > > It was that simple, surp
1 - 100 of 491 matches
Mail list logo
