Re: Crash or hang if SIGSEGV+SIGALRM are nested

On Wed, 28 May 2025 21:57:07 +0900 Takashi Yano wrote: > Hi Christian, > > On Mon, 19 May 2025 12:55:46 +0200 > Christian Franke wrote: > > The attached testcase was originally intended to investigate why a > > SIGSEGV from non-signal code could interrupt an already running signal > > handler. >

Re: Crash or hang if SIGSEGV+SIGALRM are nested

Hi Christian, On Mon, 19 May 2025 12:55:46 +0200 Christian Franke wrote: > The attached testcase was originally intended to investigate why a > SIGSEGV from non-signal code could interrupt an already running signal > handler. > https://sourceware.org/pipermail/cygwin-patches/2025q2/013703.html >

Re: FIFO hangs (Probably a bug of cygwin fifo)

On Fri, 16 May 2025 15:08:16 -0400 Ken Brown wrote: > On 5/16/2025 4:59 AM, Takashi Yano via Cygwin wrote: > > On Fri, 16 May 2025 08:46:40 +0900 > > Takashi Yano wrote: > >> diff --git a/winsup/cygwin/local_includes/cygheap.h > >> b/winsup/cygwin/local_includ

Re: strace: infinite exception c0000005 loop on segmentation fault

Hi Jon, On Fri, 16 May 2025 21:14:00 +0900 Takashi Yano via Cygwin wrote: > On Fri, 16 May 2025 13:46:21 +0200 > Christian Franke wrote: > > Testcase: > > > > $ uname -r # Also occurs with 3.6.1-1.x86_64 > > 3.7.0-0.95.g854150fda310.x86_64 > &g

Re: strace: infinite exception c0000005 loop on segmentation fault

Hi Christian, Thanks for the report. On Fri, 16 May 2025 13:46:21 +0200 Christian Franke wrote: > Found during check why SIGSEGV handler could interrupt SIGALRM handler > (which does not happen on Linux): > https://sourceware.org/pipermail/cygwin-patches/2025q2/013703.html Perhaps, delay of cal

Re: FIFO hangs (Probably a bug of cygwin fifo)

On Fri, 16 May 2025 08:46:40 +0900 Takashi Yano wrote: > diff --git a/winsup/cygwin/local_includes/cygheap.h > b/winsup/cygwin/local_includes/cygheap.h > index fed87ec2b..7d11fbb37 100644 > --- a/winsup/cygwin/local_includes/cygheap.h > +++ b/winsup/cygwin/local_includes/cygheap.h > @@ -604,6 +604

Re: FIFO hangs (Probably a bug of cygwin fifo)

Hi Ken, On Thu, 15 May 2025 18:18:26 -0400 Ken Brown wrote: > Hi Takashi, > > On 5/14/2025 5:29 AM, Takashi Yano via Cygwin wrote: > > Hi Ken, > > > > I encountered the problem with fifo. The following STC hangs > > in cygwin while it works in linux. >

FIFO hangs (Probably a bug of cygwin fifo)

Hi Ken, I encountered the problem with fifo. The following STC hangs in cygwin while it works in linux. Perhaps, cygheap->fdtab.lock() causes a deadlock between both open(). Could you please take a look? #include #include #include #include #define fifo1 "/tmp/fifo-test" void *thr1(void *)

Re: Hang or crash after multiple SIGILL or SIGSEGV and siglongjmp

On Tue, 25 Mar 2025 14:38:35 +0100 Christian Franke wrote: > Found because 'stress-ng --priv-instr ...' hangs and then requires > '/bin/kill --force ...': > > Testcase with >   [PATCH v2] Cygwin: signal: Copy context to alternate stack in the > SA_ONSTACK case > already applied: > > $ uname -r

Re: bug with cygserver-config not working anymore

On Wed, 30 Apr 2025 21:30:16 + Christian Lupien wrote: > On a recent system install, I tried to install cygserver by executing > cygserver-config > but it failed saying that cygserver was already running. > > I have done that same install for many years with success. > > I tracked down the p

Re: git testsuite "t1004-read-tree-m-u-wf.sh" test hang with Cygwin 3.7.0 ...

On Mon, 21 Apr 2025 21:54:03 +0200 Roland Mainz via Cygwin wrote: > Hi! > > > > Running the git testsuite I got a hang of the > "t1004-read-tree-m-u-wf.sh" test in Cygwin 3.7 - the same test worked > AFAIK OK with Cygwin 3.5.x. > > My guess: |wait_sig()| and |_sigfe()| are involved, maybe

Re: /dev/null regression in Cygwin 3.6.1

On Sun, 20 Apr 2025 19:15:42 +0200 Bruno Haible wrote: > Hi, > > Takashi Yano wrote: > > > > Thanks for the new testcase. I think the issue has been fixed in: > > > > cygwin-3.7.0-0.68.g37c49decc835 (Test) > > > > > > Thanks. > > > > > > > Please test. > > > > > > Sorry, I don't know how to bui

Rust for cygwin (was Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key)

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? > > Theoretically yes. Actually once a GitHub user @Ookiineko succeed

Re: /dev/null regression in Cygwin 3.6.1

On Tue, 15 Apr 2025 11:33:55 +0200 Bruno Haible wrote: > Takashi Yano wrote: > > Thanks for the new testcase. I think the issue has been fixed in: > > cygwin-3.7.0-0.68.g37c49decc835 (Test) > > Thanks. > > > Please test. > > Sorry, I don't know how to build Cygwin from git. I can only test > rel

Re: /dev/null regression in Cygwin 3.6.1

On Tue, 15 Apr 2025 21:58:19 +0900 Takashi Yano via Cygwin wrote: > On Tue, 15 Apr 2025 06:43:33 -0600 > Brian Inglis via Cygwin wrote: > > On 2025-04-15 03:33, Bruno Haible via Cygwin wrote: > > > Takashi Yano wrote: > > >> Thanks for the new testcase. I

Re: /dev/null regression in Cygwin 3.6.1

On Tue, 15 Apr 2025 06:43:33 -0600 Brian Inglis via Cygwin wrote: > On 2025-04-15 03:33, Bruno Haible via Cygwin wrote: > > Takashi Yano wrote: > >> Thanks for the new testcase. I think the issue has been fixed in: > >> cygwin-3.7.0-0.68.g37c49decc835 (Test) > > > > Thanks. > > > >> Please test.

cygwin workflow completed, but not available in mirror servers

Hi Jon, It seems something is went wrong with workflow. The workflow is successfully completed, however no cygwin Test release has not been available in any of mirror server. The newest test release in the mirror servers is cygwin-3.7.0-0.55.g1c530c37fd63, while the the latest test release which

cygwin workflow completed, but not available in mirror servers

Hi Jon, It seems something is went wrong with workflow. The workflow is successfully completed, however no cygwin Test release has not been available in any of mirror server. The newest test release in the mirror servers is cygwin-3.7.0-0.55.g1c530c37fd63, while the the latest test release which

Re: /dev/null regression in Cygwin 3.6.1

On Mon, 14 Apr 2025 15:03:16 +0200 Bruno Haible wrote: > Here's a smaller reproducer. > > foo.c > #include > #include > #include > > int main () > { > HANDLE h = (HANDLE) _get_osfhandle (0); > fprintf (stderr, "h = 0x%08x\n", h); >

Re: /dev/null regression in Cygwin 3.6.1

Hi Bruno, On Sat, 12 Apr 2025 15:21:12 +0200 Bruno Haible wrote: > Hi, > > In Gnulib, we have a unit test that compiles the program below as a > native Windows program (either with mingw or with MSVC), that exercises > the Gnulib select() function > >

Re: ctrl-c issues in 3.6.1?

On Thu, 10 Apr 2025 10:39:02 -0700 (PDT) Jeremy Drake wrote: > 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 >

Re: ctrl-c issues in 3.6.1?

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 > target), and I'm noticing after updating to 3.6.1 it no longer seems to > cancel the build whe

Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key

On Sun, 23 Mar 2025 20:32:44 +0800 Yuyi Wang wrote: > It's a bug when I tried to run tests of Rust std lib. The standard > library of Rust tries to create a new pthread_key in the destructor of a > key created previously. Unfortunately, List::for_each locked the mutex > before, so List_insert metho

Re: unix socket hang when connect

On Mon, 7 Apr 2025 15:08:32 +0800 Yuyi Wang wrote: > Below is a simple unix socket testing code. It creates a unix socket server > and > a client to connect to it immediately. It works on Linux and macOS, but hangs > on > cygwin. bind + listen work well, but seems that the connect method never

Re: Crashes in cmake subprocesses since 3.6.0

On Wed, 2 Apr 2025 23:41:46 -0700 (PDT) Jeremy Drake wrote: > 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() bef

Re: Crashes in cmake subprocesses since 3.6.0

On Thu, 3 Apr 2025 12:32:35 +0900 Takashi Yano wrote: > > Still, I wonder in which thread raw_write is running during fork(). > > Weird enough, raw_write() is called in the main thread (_main_tls). > Any chance, fixup_after_fork() is not called? It seems that raw_write() is called before returnin

Re: Crashes in cmake subprocesses since 3.6.0

On Wed, 2 Apr 2025 20:15:54 +0200 Corinna Vinschen wrote: > Hi Takashi, > > On Apr 3 01:52, Takashi Yano via Cygwin wrote: > > > Currently, I am looking into this problem. > > > > > > What I noticed so far is: > > > * The problem occurs after the

Re: Crashes in cmake subprocesses since 3.6.0

On Wed, 2 Apr 2025 22:01:25 +0900 Takashi Yano via Cygwin wrote: > Hi Corinna, > > On Mon, 31 Mar 2025 11:28:44 +0200 > Corinna Vinschen wrote: > > On Mar 30 22:58, Jeremy Drake via Cygwin wrote: > > > On Mon, 31 Mar 2025, Christoph Reiter via Cygwin wrote: > &g

Re: Crashes in cmake subprocesses since 3.6.0

Hi Corinna, On Mon, 31 Mar 2025 11:28:44 +0200 Corinna Vinschen wrote: > On Mar 30 22:58, Jeremy Drake via Cygwin wrote: > > 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, f

Re: SIGSEGV handling and stack overflow handling broken in Cygwin 3.6.0

On Mon, 24 Mar 2025 22:52:04 +0900 Takashi Yano wrote: > On Mon, 24 Mar 2025 13:26:27 +0100 > Bruno Haible wrote: > > Hi, > > > > Gnulib contains a few unit tests for > > - SIGSEGV handling, > > - stack overflow handling (via signal SIGSEGV or SIGBUS). > > > > In Cygwin 3.4.6, SISGEGV handlin

Re: SIGSEGV handling and stack overflow handling broken in Cygwin 3.6.0

On Mon, 24 Mar 2025 13:26:27 +0100 Bruno Haible wrote: > Hi, > > Gnulib contains a few unit tests for > - SIGSEGV handling, > - stack overflow handling (via signal SIGSEGV or SIGBUS). > > In Cygwin 3.4.6, SISGEGV handling was fine, and stack overflow handling > worked at least for the first s

Re: Deadlock when calling pthread_key_create in the destructor of a pthread_key

On Sun, 23 Mar 2025 20:32:44 +0800 Yuyi Wang wrote: > It's a bug when I tried to run tests of Rust std lib. The standard > library of Rust tries to create a new pthread_key in the destructor of a > key created previously. Unfortunately, List::for_each locked the mutex > before, so List_insert metho

Re: STATUS_HEAP_CORRUPTION if signal arrives when x86 direction flag is set

On Sun, 23 Mar 2025 12:54:36 +0100 Christian Franke wrote: > Found because 'stress-ng --memcpy ...' and other tests report segfaults: > > An exception 0xc374 (STATUS_HEAP_CORRUPTION) occurs if a signal > arrives during a memmove() which copies backwards due to overlap. > > The related snippe

Re: LOCAL_APPDATA_FONTCONFIG_CACHE directories are popping up everywhere

On Sun, 16 Mar 2025 12:08:28 +0900 Takashi Yano wrote: > On Sat, 15 Mar 2025 19:38:20 -0600 > Jim Reisert AD1C via Cygwin wrote: > > > Recently, I seem to have LOCAL_APPDATA_FONTCONFIG_CACHE directories > > popping up everywhere: > > > > ./DX4WIN/awd/RDA/LOCAL_APPDATA_FONTCONFIG_CACHE > > ./DX

Re: LOCAL_APPDATA_FONTCONFIG_CACHE directories are popping up everywhere

On Sat, 15 Mar 2025 19:38:20 -0600 Jim Reisert AD1C via Cygwin wrote: > Recently, I seem to have LOCAL_APPDATA_FONTCONFIG_CACHE directories > popping up everywhere: > > ./DX4WIN/awd/RDA/LOCAL_APPDATA_FONTCONFIG_CACHE > ./DXspots/LOCAL_APPDATA_FONTCONFIG_CACHE > ./QSL/address/LOCAL_APPDATA_FONTCO

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 15:18:45 +0100 Corinna Vinschen wrote: > On Mar 14 21:52, Takashi Yano via Cygwin wrote: > > On Fri, 14 Mar 2025 13:19:28 +0100 > > Corinna Vinschen wrote: > > > On Mar 14 20:35, Takashi Yano via Cygwin wrote: > > > > On Fri, 14 Mar 2025 11:

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 13:19:28 +0100 Corinna Vinschen wrote: > On Mar 14 20:35, Takashi Yano via Cygwin wrote: > > On Fri, 14 Mar 2025 11:01:25 +0100 > > Corinna Vinschen wrote: > > > I don't think so. I was mulling in circles over this tonight > > > (don'

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 11:01:25 +0100 Corinna Vinschen wrote: > On Mar 14 12:56, Takashi Yano via Cygwin wrote: > > On Fri, 14 Mar 2025 08:12:36 +0900 > > Takashi Yano wrote: > > > On Thu, 13 Mar 2025 23:46:49 +0100 > > > Corinna Vinschen wrote: > > > &g

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 08:18:41 +0900 Takashi Yano wrote: > On Fri, 14 Mar 2025 08:12:36 +0900 > Takashi Yano wrote: > > On Thu, 13 Mar 2025 23:46:49 +0100 > > Corinna Vinschen wrote: > > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote: > > > > On Mar

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 08:12:36 +0900 Takashi Yano wrote: > On Thu, 13 Mar 2025 23:46:49 +0100 > Corinna Vinschen wrote: > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote: > > > On Mar 13 21:31, Takashi Yano via Cygwin wrote: > > > > What about following patch

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Fri, 14 Mar 2025 08:12:36 +0900 Takashi Yano wrote: > On Thu, 13 Mar 2025 23:46:49 +0100 > Corinna Vinschen wrote: > > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote: > > > On Mar 13 21:31, Takashi Yano via Cygwin wrote: > > > > What about following patch

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Thu, 13 Mar 2025 23:46:49 +0100 Corinna Vinschen wrote: > On Mar 13 17:30, Corinna Vinschen via Cygwin wrote: > > On Mar 13 21:31, Takashi Yano via Cygwin wrote: > > > What about following patch instead of your sigdelayed patch? > > > [...] > >

Re: cygwin 3.6.0: No signals received after swapcontext() is used

On Thu, 13 Mar 2025 20:42:52 +0900 Takashi Yano wrote: > Hi Corinna, > > On Thu, 13 Mar 2025 10:40:48 +0100 > Christian Franke wrote: > > Corinna Vinschen via Cygwin wrote: > > > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote: > > >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: > > >>>

Re: cygwin 3.6.0: No signals received after swapcontext() is used

Hi Corinna, On Thu, 13 Mar 2025 10:40:48 +0100 Christian Franke wrote: > Corinna Vinschen via Cygwin wrote: > > On Mar 12 17:06, Corinna Vinschen via Cygwin wrote: > >> On Mar 12 16:30, Corinna Vinschen via Cygwin wrote: > >>> On Mar 11 12:32, Christian Franke via Cygwin wrote: > The attached

Re: lost signal (was: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP)

On Fri, 7 Mar 2025 16:29:51 +0900 Takashi Yano wrote: > On Wed, 5 Mar 2025 11:23:26 +0100 > Christian Franke wrote: > > Takashi Yano via Cygwin wrote: > > > On Mon, 24 Feb 2025 11:29:59 +0100 > > > Christian Franke wrote: > > >> Found with 's

Re: lost signal (was: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP)

On Wed, 5 Mar 2025 11:23:26 +0100 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > On Mon, 24 Feb 2025 11:29:59 +0100 > > Christian Franke wrote: > >> Found with 'stress-ng --cpu-sched 1': > >> > >> Testcase (attached): > &

Re: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP

On Mon, 24 Feb 2025 11:29:59 +0100 Christian Franke wrote: > Found with 'stress-ng --cpu-sched 1': > > Testcase (attached): > > $ uname -r > 3.6.0-0.387.g8cebbb2b42bf.x86_64 > > $ gcc -o timersig timersig.c > > $ ./timersig > 638: fork()=639 > !...!SIGSTOP: Permission de

Re: [regression-3.6] Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses characters

On Wed, 19 Feb 2025 16:23:41 +0900 Takashi Yano wrote: > On Wed, 19 Feb 2025 07:59:00 +0100 > Cedric Blancher wrote: > > Good morning! > > > > Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit: > > > > Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses > > characters. We do no

Re: [Bug] libtool (was Re: lost output after pipe redirection)

On Wed, 19 Feb 2025 17:22:53 +0100 ASSI wrote: > Takashi Yano via Cygwin writes: > > I think I have found the cause. It is an upstream bug of libtool. > > The function check_executable() generated by ltmain.sh returns 1 > > for directory, but this is not correct behaviour,

[Bug] libtool (was Re: lost output after pipe redirection)

Hi Achim, On Wed, 19 Feb 2025 21:58:49 +0900 Takashi Yano wrote: > On Wed, 19 Feb 2025 20:42:05 +0900 > Takashi Yano wrote: > > On Wed, 19 Feb 2025 07:38:13 +0900 > > Takashi Yano wrote: > > > On Tue, 18 Feb 2025 21:59:36 +0100 > > > Marco Atzeriwrote: >

Re: lost output after pipe redirection

On Wed, 19 Feb 2025 20:42:05 +0900 Takashi Yano wrote: > On Wed, 19 Feb 2025 07:38:13 +0900 > Takashi Yano wrote: > > On Tue, 18 Feb 2025 21:59:36 +0100 > > Marco Atzeriwrote: > > > On 18/02/2025 12:56, Takashi Yano via Cygwin wrote: > > > > Hi Marco, > &

Re: lost output after pipe redirection

On Wed, 19 Feb 2025 07:38:13 +0900 Takashi Yano wrote: > On Tue, 18 Feb 2025 21:59:36 +0100 > Marco Atzeriwrote: > > On 18/02/2025 12:56, Takashi Yano via Cygwin wrote: > > > Hi Marco, > > > > > > On Mon, 17 Feb 2025 09:28:11 +0100 > > > Marco

Re: [regression-3.6] Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses characters

On Wed, 19 Feb 2025 07:59:00 +0100 Cedric Blancher wrote: > Good morning! > > Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit: > > Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses > characters. We do not have a reproducer yet, but it is happening at > least hourly on our t

Re: [regression-3.6] Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses characters

On Wed, 19 Feb 2025 07:59:00 +0100 Cedric Blancher wrote: > Good morning! > > Cygwin 3.6.0-0.374.g4dd859d01c22.x86_64 on Win10/AMD64/64bit: > > Pipe between Cygwin and non Cygwin (CRT/URT) randomly loses > characters. We do not have a reproducer yet, but it is happening at > least hourly on our t

Re: [CALL FOR TESTING] Cygwin-3.6.0

On Wed, 19 Feb 2025 01:20:59 +0100 Lionel Cons wrote: > Something is very wrong with bash. If I redirect the output of xcopy > or icacls into a bash variable, like stdout="$(icacls "$(cygpath -w > "$PWD")")", then sometimes I get only a letter in the middle. Very > strange Thanks for the report. B

Re: lost output after pipe redirection

On Tue, 18 Feb 2025 21:59:36 +0100 Marco Atzeriwrote: > On 18/02/2025 12:56, Takashi Yano via Cygwin wrote: > > Hi Marco, > > > > On Mon, 17 Feb 2025 09:28:11 +0100 > > Marco Atzeri wrote: > >> Hi Takashi, > >> > >> I think there is still

Re: lost output after pipe redirection

Hi Marco, On Mon, 17 Feb 2025 09:28:11 +0100 Marco Atzeri wrote: > Hi Takashi, > > I think there is still issue on pipe redirection output lost. > I have two cases where during package tests the test are reported as > failures as the output is missing, while running the test stand alone > the o

Re: Updated: vim-9.1.1054-1

Hi Marco, On Wed, 29 Jan 2025 16:23:03 +0100 Marco Atzeri wrote: > On 29/01/2025 16:02, Takashi Yano via Cygwin wrote: > > Hi Achim, > > > > On Wed, 29 Jan 2025 13:30:16 +0100 > > ASSI wrote: > >> Marco Atzeri via Cygwin writes: > >>> It wo

Re: Updated: vim-9.1.1054-1

Hi Achim, On Wed, 29 Jan 2025 13:30:16 +0100 ASSI wrote: > Marco Atzeri via Cygwin writes: > > It works fine from my side and there were no patch on filetypes.vim so > > it is vanilla based. > > Hmmm… it actually works when I explicitly start vim, but I get the error > when I start vi. I have an

[mintty] Problem of the control key on focus change

Hi Thomas, A few days ago, Corinna asked me to check a problem of TTY. The problem is as follows. Reproduce steps: (1) Open mintty. (2) Open another mintty. (3) Place the second mintty window over the first one. (4) Hold ctrl key down. (5) Press 'd' key while holding ctrl key. The second mintty

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Fri, 24 Jan 2025 10:55:18 +0100 Michael Soegtrop wrote: > Dear Cygwin Team, > > I just wanted to confirm that I haven't seen issues with recent test > releases. But the test versions change to fast to say conclusively that > each of the versions are OK. > > The last version for which I did s

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Wed, 22 Jan 2025 10:42:39 -0800 (PST) Jeremy Drake wrote: > 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 confirmati

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Mon, 20 Jan 2025 10:48:55 +0100 Michael Soegtrop wrote: > Dear Cygwin Team, > > apparently there was a change in the test release (what I get when I run > cygwin setup with --allow-test-packages) in the last few days. With the > latest test release I see CI failures again with the same effect

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Tue, 14 Jan 2025 19:26:47 +0100 Michael Soegtrop wrote: > Dear Cygwin Team, > > > I personally prefer releasing 3.5.6 ASAP > > Indeed this is also my preference - if it can be fixed soon (say this week). > > > Can you please test latest cygwin 3.6.0 (TEST) > > Even though I am using cygwin

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

Hi Michael, On Tue, 14 Jan 2025 09:17:23 +0900 Takashi Yano wrote: > On Mon, 13 Jan 2025 16:10:17 -0800 (PST) > Jeremy Drake wrote: > > On Tue, 14 Jan 2025, Takashi Yano via Cygwin wrote: > > > > > Hi Michael, > > > > > > Personally, I person

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Mon, 13 Jan 2025 16:10:17 -0800 (PST) Jeremy Drake wrote: > 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 t

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

On Tue, 14 Jan 2025 08:57:36 +0900 Takashi Yano wrote: > Hi Michael, > > On Fri, 10 Jan 2025 08:48:00 +0100 > Michael Soegtrop wrote: > > sending again, since this did not appear in the archives ... > > > > Dear Cygwin Team, > > > > I wanted to discuss the status of the hangs in cygwin 3.5.5-1 d

Re: Hangs in cygwin 3.5.5-1: should 3.5.5-1 be rolled back?

Hi Michael, On Fri, 10 Jan 2025 08:48:00 +0100 Michael Soegtrop wrote: > sending again, since this did not appear in the archives ... > > Dear Cygwin Team, > > I wanted to discuss the status of the hangs in cygwin 3.5.5-1 discussed > in various threads here. I maintain the multi platform distri

Re: Updated: GraphicsMagick-1.3.45-1

On Tue, 31 Dec 2024 18:59:03 +0100 Marco Atzeri wrote: > On 31/12/2024 17:28, Marco Atzeri wrote: > > On 31/12/2024 14:36, Takashi Yano via Cygwin wrote: > >> On Wed, 18 Dec 2024 09:54:24 +0100 > >> Marco Atzeri wrote: > >>> Version 1.3.45-1 of > > >

Re: Updated: GraphicsMagick-1.3.45-1

On Wed, 18 Dec 2024 09:54:24 +0100 Marco Atzeri wrote: > Version 1.3.45-1 of > GraphicsMagick > libGraphicsMagick-devel > libGraphicsMagick3 > libGraphicsMagick++12 > libGraphicsMagickWand2 > perl-Graphics-Magick > > have been uploaded for cygwin > > CHANGES > Upstream sec

Re: Anomaly in CRON execution of shell script

On Sat, 28 Dec 2024 17:07:10 + Chris Elvidge wrote: > I have a directory of files that I need the contained executables run > from CRON. (Like run-parts.) > > I have found that since 25/12/2024, when run from CRON, it doesn't > differentiate between executable and non-executable files. I.e.

Re: raise() produces random behaviour in Cygwin 3.5.5

On Wed, 25 Dec 2024 07:21:44 +0100 Bruno Haible wrote: > This unit test is part of Gnulib. Really, it is a pity that none of the > Cygwin maintainers is running the Gnulib tests before making a new Cygwin > release. We once discussed necessity of the test suite for cygwin before. Do you think the

Re: bash hangs on cygwin-3.5.5-1

On Wed, 25 Dec 2024 15:33:13 -0800 (PST) Jeremy Drake wrote: > 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: > > > > &g

Re: access X_OK for administrators has changed in cygwin 3.5.5

On Wed, 25 Dec 2024 01:29:47 +0100 Bruno Haible wrote: > Hi, > > The behaviour of the access(_, X_OK) call has changed for administrator > users in Cygwin 3.5.5. I don't know whether that's intended or not > (haven't seen it mentioned in >

Re: raise() produces random behaviour in Cygwin 3.5.5

On Wed, 25 Dec 2024 07:21:44 +0100 Bruno Haible wrote: > An invocation of raise(SIGABRT), that is, of a synchronous signal, produces > random behaviour in Cygwin 3.5.5: Sometimes it succeeds, sometimes it fails > with error ENOSYS. In previous releases of Cygwin and in all other operating > systems

Re: bash hangs on cygwin-3.5.5-1

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 (*), and it hung: > > $ mkdir build-cygwin64 > $ cd build-cygwin64 > $

Re: zsh (oh-my-zsh) hangs on cygwin-3.5.5-1

On Mon, 23 Dec 2024 20:30:30 +0900 Daisuke Fujimura via Cygwin wrote: > $ kill -CHLD 214 > > $ ps > PID PPID PGID WINPID TTY UID STIME COMMAND > 217 1 217 4788 cons0 197609 20:22:44 /usr/bin/bash > I 181 180 181 9652 pty0 197609 20:22:33 /usr/bin/zsh > 225 217 225 2996 cons0 197609 20:26:48 /usr/

Re: zsh (oh-my-zsh) hangs on cygwin-3.5.5-1

On Sun, 22 Dec 2024 10:59:11 +0900 Daisuke Fujimura wrote: > > Could you please test if additional SIGCHLD can release hanging? > > Start mintty and check the process from another bash. > > $ ps > PID PPID PGID WINPID TTY UID STIME COMMAND > 1713 1662 1713 6800 cons0 197609 04:26:01 /usr/bin/ps >

Re: zsh (oh-my-zsh) hangs on cygwin-3.5.5-1

On Sat, 21 Dec 2024 19:40:59 +0900 Takashi Yano wrote: > On Sat, 21 Dec 2024 12:30:02 +0900 > Daisuke Fujimura wrote: > > Sometimes the prompt does not return. > > > > $ ps > > PID PPID PGID WINPID TTY UID STIME COMMAND > > 378 294 378 5544 pty0 197609 11:26:16 /usr/bin/ps > > 351 1 294 6552 pty0

Re: zsh (oh-my-zsh) hangs on cygwin-3.5.5-1

On Sat, 21 Dec 2024 12:30:02 +0900 Daisuke Fujimura wrote: > Sometimes the prompt does not return. > > $ ps > PID PPID PGID WINPID TTY UID STIME COMMAND > 378 294 378 5544 pty0 197609 11:26:16 /usr/bin/ps > 351 1 294 6552 pty0 197609 10:13:07 /usr/bin/zsh > 293 1 293 4984 ? 197609 10:13:03 /usr/bi

Re: zsh (oh-my-zsh) hangs on cygwin-3.5.5-1

On Sat, 21 Dec 2024 12:30:02 +0900 Daisuke Fujimura via Cygwin wrote: > Sometimes the prompt does not return. > > $ ps > PID PPID PGID WINPID TTY UID STIME COMMAND > 378 294 378 5544 pty0 197609 11:26:16 /usr/bin/ps > 351 1 294 6552 pty0 197609 10:13:07 /usr/bin/zsh > 293 1 293 4984 ? 197609 10:1

Re: procps can work

On Wed, 18 Dec 2024 10:25:25 +0800 凯夏 wrote: > So, there is a big performance difference between windows and linux? > On linux, 3000 processes just take about 0.1 second. I guess some APIs of cygwin are much slower than Linux. Achim, any idea? -- Takashi Yano -- Problem reports: https://

Re: procps can work

On Thu, 12 Dec 2024 21:48:05 +0800 凯夏 wrote: > 31@21:47:19#xiakai1@tp/~> /usr/bin/ps|wc -l > 146 > 31@21:47:21#xiakai1@tp/~> > about 146 processes It is possibly just due to too many processes for procps, isn't it? I tested procps with 200 processes (sleep 100) and it took about 10 seconds. What

Re: procps can work

On Thu, 12 Dec 2024 17:01:38 +0800 凯夏 wrote: > yes, 3.6.0-0.280.g2a1f407b091, > I use timeout 3 strace procps -h &> procps.strace and split procps.strace > into two files: > https://pastebin.com/PQ5FuiLX > https://pastebin.com/i30c271t By any chance, do you have many cygwin processes running in ba

Re: [PATCH] Cygwin: signal: Fix high load when retrying to process pending signal

On Thu, 12 Dec 2024 16:43:14 +0800 凯夏 wrote: > Thank you. Does that mean I need to compile cygwin by myself? How long will > it take to publish to test? I have just pushed the patch to git master, so please wait for cygwin-3.6.0-dev-287-g1d1451ccd. It will be available in a hour or so. -- Takash

Re: procps can work

On Thu, 12 Dec 2024 14:05:29 +0800 凯夏 wrote: > Yes cannot work, just running procps or procps -h or any command except > procps -V. procps command will stuck. > > On Thu, Dec 12, 2024 at 1:25 PM Takashi Yano > wrote: > > > On Thu, 12 Dec 2024 13:14:47 +0800 > > 凯夏 wrote: > > > procps can work, h

Re: procps can work

On Thu, 12 Dec 2024 13:14:47 +0800 凯夏 wrote: > procps can work, how can i debug this? Do you mean "cannot work"? I cannot reproduce your problem. Could you please let us know the steps to reproduce? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ:

Re: cpu issue on when using less

On Thu, 12 Dec 2024 11:24:40 +0800 凯夏 via Cygwin wrote: > When I use less read from pipe,even i just output a empty new line to less, > the bash running less gets high cpu usage ( picture 1, picture 2 ), and > less itself didn't use many cpu, when i quit less, cpu usage of bash drop > to normal (

Re: SMBFS mount's file cannot be made executable

On Sun, 8 Dec 2024 08:13:38 +0900 Takashi Yano wrote: > On Tue, 19 Nov 2024 21:54:44 +0100 > Corinna Vinschen wrote: > > On Nov 19 17:58, Takashi Yano via Cygwin wrote: > > > On Mon, 18 Nov 2024 17:26:12 +0100 > > > Corinna Vinschen wrote: > > > > We

Re: SMBFS mount's file cannot be made executable

On Tue, 19 Nov 2024 21:54:44 +0100 Corinna Vinschen wrote: > On Nov 19 17:58, Takashi Yano via Cygwin wrote: > > On Mon, 18 Nov 2024 17:26:12 +0100 > > Corinna Vinschen wrote: > > > We can safely assume that the current user is already authorized on the > >

Re: Calling GetConsoleProcessList in tight loop allocates new buffer via condrv ioctl results in excessive page-faults with Windows Terminal

On Tue, 3 Dec 2024 20:42:42 +0900 Takashi Yano wrote: > On Mon, 2 Dec 2024 19:57:25 + > Steven Buehler wrote: > > I am experiencing an abnormal number of page-faults per second (averaging > > 800 to over 2000) when using Cygwin within the Windows Terminal app. This > > produces visible stutte

Re: Calling GetConsoleProcessList in tight loop allocates new buffer via condrv ioctl results in excessive page-faults with Windows Terminal

On Mon, 2 Dec 2024 19:57:25 + Steven Buehler wrote: > I am experiencing an abnormal number of page-faults per second (averaging 800 > to over 2000) when using Cygwin within the Windows Terminal app. This > produces visible stutters and cursor movement during terminal screen redraws. > > I ha

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Mon, 25 Nov 2024 21:23:45 +0900 Takashi Yano wrote: > On Sun, 24 Nov 2024 01:15:09 +0900 > Takashi Yano wrote: > > On Sat, 23 Nov 2024 16:53:21 +0100 > > Christian Franke wrote: > > > Takashi Yano via Cygwin wrote: > > > > On Wed, 20 Nov 2024 22

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Sun, 24 Nov 2024 01:15:09 +0900 Takashi Yano wrote: > On Sat, 23 Nov 2024 16:53:21 +0100 > Christian Franke wrote: > > Takashi Yano via Cygwin wrote: > > > On Wed, 20 Nov 2024 22:43:08 +0900 > > > Takashi Yano wrote: > > >> On Tue, 19 Nov 202

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Sat, 23 Nov 2024 16:53:21 +0100 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > On Wed, 20 Nov 2024 22:43:08 +0900 > > Takashi Yano wrote: > >> On Tue, 19 Nov 2024 18:21:52 +0900 > >> Takashi Yano wrote: > >>> On Tue, 12 Nov 202

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Sun, 24 Nov 2024 00:41:15 +0900 Takashi Yano via Cygwin wrote: > On Sat, 23 Nov 2024 20:53:07 +0900 > Takashi Yano wrote: > > The patch attached almost solves the problem. However, your test > > case is paused for tens of seconds, then ends normally. > > > > If

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Sat, 23 Nov 2024 20:53:07 +0900 Takashi Yano wrote: > The patch attached almost solves the problem. However, your test > case is paused for tens of seconds, then ends normally. > > If the code: > cpu_set_t cpus; CPU_ZERO(&cpus); > CPU_SET(0, &cpus); > if (sched_setaffinity(get

Re: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals

On Wed, 20 Nov 2024 22:43:08 +0900 Takashi Yano wrote: > On Tue, 19 Nov 2024 18:21:52 +0900 > Takashi Yano wrote: > > On Tue, 12 Nov 2024 10:53:58 +0100 > > Christian Franke wrote: > > > Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD: > > > > > > Testcase (attached): > > >

Re: Cygwin zh_CN.GB18030 locale?

On Thu, 21 Nov 2024 06:55:07 +0100 Dan Shelton wrote: > On Thu, 21 Nov 2024 at 05:05, Thomas Wolff via Cygwin > wrote: > > Am 21.11.2024 um 00:16 schrieb Dan Shelton via Cygwin: > > > Hello! > > > > > > Does Cygwin have a zh_CN.GB18030 locale? > > > LC_ALL=zh_CN.GB18030 locale charmap > > GB180

Re: Cygwin zh_CN.GB18030 locale?

On Thu, 21 Nov 2024 00:16:41 +0100 Dan Shelton wrote: > Does Cygwin have a zh_CN.GB18030 locale? I think so. $ locale LANG=zh_CN.GB18030@cjknarrow LC_CTYPE="zh_CN.GB18030@cjknarrow" LC_NUMERIC="zh_CN.GB18030@cjknarrow" LC_TIME="zh_CN.GB18030@cjknarrow" LC_COLLATE="zh_CN.GB18030@cjknarrow" LC_MONE

  1   2   3   4   5   6   >