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

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

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): > > > > $ gcc -O2 -o manysignals manysignals.c > > > > $ ./manysignals >

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

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): > > $ gcc -O2 -o manysignals manysignals.c > > $ ./manysignals > fork() = 1833 > ... > fork() = 1848 > ... > kill(1833, 17) > ... > kill(

Re: SMBFS mount's file cannot be made executable

On Mon, 18 Nov 2024 17:26:12 +0100 Corinna Vinschen wrote: > On Nov 16 00:21, Takashi Yano via Cygwin wrote: > > I built a test program, whose important part is: > > > > AUTHZ_RESOURCE_MANAGER_HANDLE hManager = NULL; > > AUTHZ_CLIENT_CONTEXT_HANDLE hClient = NULL;

Re: Segfault in pthread_sigqueue() or sigtimewait()

On Thu, 14 Nov 2024 13:55:36 +0100 Christian Franke wrote: > After enabling the usage of pthread_sigqueue() in stress-ng, 'stress-ng > --pthread ...' occasionally reports that child processes failed with > SIGSEGV. > > The problem is unrelated to the recent fix of the signature of > pthread_sig

Re: SMBFS mount's file cannot be made executable

On Thu, 14 Nov 2024 01:08:07 +0900 Takashi Yano wrote: > On Wed, 13 Nov 2024 08:58:21 -0700 > Bill Stewart wrote: > > On Wed, Nov 13, 2024 at 8:38 AM Takashi Yano via Cygwin wrote: > > > > Thanks. However, even after reading the document, I still didn't > > >

Re: SMBFS mount's file cannot be made executable

On Wed, 13 Nov 2024 08:58:21 -0700 Bill Stewart wrote: > On Wed, Nov 13, 2024 at 8:38 AM Takashi Yano via Cygwin wrote: > > Thanks. However, even after reading the document, I still didn't > > understand what strings I should set the members for auth for SMB... > &g

Re: stress-ng --lockmix 1 crashes with *** fatal error - NtCreateEvent(lock): 0xC0000035

On Tue, 12 Nov 2024 15:28:41 +0100 Sebastian Feld wrote: > stress-ng --lockmix 1 crashes on CYGWIN_NT-10.0-19045 > 3.6.0-0.229.g87cd4f3fbd06.x86_64 > > $ stress-ng --lockmix 1 > stress-ng: info: [174] defaulting to a 1 day run per stressor > stress-ng: info: [174] dispatching hogs: 1 lockmix >

Re: SMBFS mount's file cannot be made executable

On Wed, 13 Nov 2024 08:10:52 -0700 Bill Stewart wrote: > On Wed, Nov 13, 2024 at 2:18 AM Takashi Yano via Cygwin wrote: > > I'm working on this, however, I stuck on setting the first parameter > > of AuthzInitializeRemoteResourceManager(). The most

Re: SMBFS mount's file cannot be made executable

Hi Corinna, On Tue, 12 Nov 2024 12:56:15 +0100 Corinna Vinschen wrote: > On Nov 12 17:54, Takashi Yano via Cygwin wrote: > > I noticed that the probelm is not only in samba share, but > > also in Windows share. > > > > Yesterday, I used shared resource of the root

Re: SMBFS mount's file cannot be made executable

On Tue, 12 Nov 2024 04:29:37 +0900 Takashi Yano wrote: > On Mon, 11 Nov 2024 14:35:55 +0100 > Corinna Vinschen wrote: > > On Nov 11 21:19, Takashi Yano via Cygwin wrote: > > > On Mon, 11 Nov 2024 13:03:18 +0100 > > > Corinna Vinschen wrote: > > > > On N

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 14:35:55 +0100 Corinna Vinschen wrote: > On Nov 11 21:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 13:03:18 +0100 > > Corinna Vinschen wrote: > > > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > > > On Mon, 11 Nov 2024 20:

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 12:59:41 +0100 Corinna Vinschen wrote: > On Nov 11 20:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 11:56:13 +0100 > > Corinna Vinschen wrote: > > > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > > On Fri,

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 12:59:41 +0100 Corinna Vinschen wrote: > On Nov 11 20:19, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 11:56:13 +0100 > > Corinna Vinschen wrote: > > > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > > On Fri,

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 13:03:18 +0100 Corinna Vinschen wrote: > On Nov 11 20:40, Takashi Yano via Cygwin wrote: > > On Mon, 11 Nov 2024 20:32:02 +0900 > > Takashi Yano via Cygwin wrote: > > > Even with this patch, the file: > > > > > > yano $ to

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 20:19:28 +0900 Takashi Yano wrote: > On Mon, 11 Nov 2024 11:56:13 +0100 > Corinna Vinschen wrote: > > > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > > On Fri, 8 Nov 2024 14:11:40 +0100 > > > Corinna Vinschen wrote: > > >

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 20:32:02 +0900 Takashi Yano via Cygwin wrote: > Even with this patch, the file: > > yano $ touch samba_test_file.txt > yano $ ls -l samba_test_files.txt > -rw-r--r-- 1 yano yano 0 Nov 11 20:25 samba_test_file.txt Oops! This was wrong. -rw-r--r-- 1 Unknown+

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 20:19:28 +0900 Takashi Yano via Cygwin wrote: > On Mon, 11 Nov 2024 11:56:13 +0100 > Corinna Vinschen wrote: > > > diff --git a/winsup/cygwin/sec/base.cc b/winsup/cygwin/sec/base.cc > > > index d5e39d281..c519af6e0 100644 > > > --- a/wins

Re: SMBFS mount's file cannot be made executable

On Mon, 11 Nov 2024 11:56:13 +0100 Corinna Vinschen wrote: > On Nov 11 19:31, Takashi Yano via Cygwin wrote: > > On Fri, 8 Nov 2024 14:11:40 +0100 > > Corinna Vinschen wrote: > > > If the server is a Samba share, check if `force unknown acl user = yes' > > >

Re: SMBFS mount's file cannot be made executable

Hi Corinna, On Fri, 8 Nov 2024 14:11:40 +0100 Corinna Vinschen wrote: > On Nov 8 20:51, Takashi Yano via Cygwin wrote: > > Hi all, > > > > On Thu, 8 Aug 2019 15:41:55 + > > "Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > > > Hi, > > > > &

Re: [EXTERNAL] Re: SMBFS mount's file cannot be made executable

On Fri, 8 Nov 2024 16:07:11 + "Lavrentiev, Anton (NIH/NLM/NCBI) [C]" wrote: > I had the issue at work and I asked my Systems team to configure the share > correctly on the Linux side of the things. > > Y: on /cygdrive/y type smbfs (binary,posix=0,user,noumount,auto) > Z: on /cygdrive/z type s

Re: SMBFS mount's file cannot be made executable

Hi all, On Thu, 8 Aug 2019 15:41:55 + "Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi, > > Here's the situation, I have a netmount "Z:" but I cannot make any files on > it executable from Cygwin: > > $ mount > ... > Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) > > $ c

Re: Problem with building LibreOffice in Cygwin 3.5.0 (child_info::sync: wait failed)

On Mon, 12 Feb 2024 08:51:38 +0200 Ilmari Lauhakangas wrote: > We have multiple developers on Windows 11 reporting that Cygwin 3.5.0 > has a regression that makes building LibreOffice fail with these types > of messages: > > 0 [main] sh 1280 child_info::sync: wait failed, pid 1288, Win32 error 1

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

t; > > > > > On Sun, 13 Oct 2024 16:19:31 -0600 > > > Brian Inglis wrote: > > > > On 2024-10-13 14:06, Takashi Yano via Cygwin wrote: > > > > > Hi Brian > > > > > > > > > > On Sun, 13 Oct 2024

Re: cygwin 3.5.4-1: lockf() aborts on overlap and does not fail on overflow

On Thu, 17 Oct 2024 18:37:57 +0200 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > On Mon, 14 Oct 2024 15:36:02 +0200 > > Christian Franke wrote: > >> Two possibly independent bugs found by 'stress-ng --lockf ...': > >> > >> 1) lockf

Re: cygwin 3.5.4-1: lockf() aborts on overlap and does not fail on overflow

On Mon, 14 Oct 2024 15:36:02 +0200 Christian Franke wrote: > Two possibly independent bugs found by 'stress-ng --lockf ...': > > 1) lockf() may abort the process with api_fatal() if the new range > partly overlaps with two ranges previously locked by the same process. > > 2) lockf() prints a war

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Tue, 15 Oct 2024 14:38:07 -0700 jeff wrote: > On 10/15/2024 14:34, Takashi Yano wrote: > > On Tue, 15 Oct 2024 13:09:12 -0700 > > jeff wrote: > >> /cygdrive/k/pw-crack/fred_john/run/cygwin1.dll > >> -rwxrwx---+ 1 jdeifik None 3492318 May 26  2019 > > The culprit of the problem is this old cygwin

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Tue, 15 Oct 2024 13:09:12 -0700 jeff wrote: > /cygdrive/k/pw-crack/fred_john/run/cygwin1.dll > -rwxrwx---+ 1 jdeifik None 3492318 May 26  2019 The culprit of the problem is this old cygwin1.dll. Windows searches .dll in the current directory first. -- Takashi Yano -- Problem reports:

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Wed, 16 Oct 2024 00:29:30 +0900 Takashi Yano wrote: > IFS=':'; for a in ${PATH[@]}; do find $a -name cygwin1.dll -exec ls -l '{}' > \; ; done Sorry, use IFS=':'; for a in ${PATH[@]}; do find $a -maxdepth 1 -name cygwin1.dll -exec ls -l '{}' \; ; done instead. -- Takashi Yano -- Problem r

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Wed, 16 Oct 2024 00:01:44 +0900 Takashi Yano wrote: > On Tue, 15 Oct 2024 04:52:12 -0700 > jeff wrote: > > On 10/15/2024 03:48, Takashi Yano wrote: > > > On Mon, 14 Oct 2024 14:18:04 -0700 > > > jeff via Cygwin wrote: > > > > > >> I have a test case. > > >> > > >> this is test.c: > > >> #includ

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Tue, 15 Oct 2024 04:52:12 -0700 jeff wrote: > On 10/15/2024 03:48, Takashi Yano wrote: > > On Mon, 14 Oct 2024 14:18:04 -0700 > > jeff via Cygwin wrote: > > > >> I have a test case. > >> > >> this is test.c: > >> #include > >> int    main(int argc, char *argv[]) > >> { > >>     for (int i =

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Mon, 14 Oct 2024 14:18:04 -0700 jeff via Cygwin wrote: > I have a test case. > > this is test.c: > #include > int    main(int argc, char *argv[]) > { >     for (int i = 0; i < argc; i++) >     printf("%s\n", argv[i]); > } > > compiled with gcc test.c -o testx.exe > > when run from window

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Mon, 14 Oct 2024 12:31:37 -0700 jeff wrote: > On 10/14/2024 12:21, Takashi Yano wrote: > > On Mon, 14 Oct 2024 09:15:02 -0700 > > jeff wrote: > >> I wrote a program called lines.cpp, which is line wc. > >> It works fine when I run it from a windows terminal or windows command. > >> > >> When I r

Re: fresh install, when I run a c++ program I made from a cygterm it logs out

On Mon, 14 Oct 2024 09:15:02 -0700 jeff wrote: > I wrote a program called lines.cpp, which is line wc. > It works fine when I run it from a windows terminal or windows command. > > When I run it from bash, on my u disk, it works fine: > > jdeifik@epyc-milan-64 /cygdrive/u > $ lines john.conf > c:

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

On Mon, 14 Oct 2024 14:29:58 +0900 Takashi Yano wrote: > Hi Brian, > > Thanks for the detail expression. ^^ explanation -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

On Mon, 14 Oct 2024 14:59:40 +0900 Takashi Yano wrote: > On Mon, 14 Oct 2024 14:29:58 +0900 > Takashi Yano wrote: > > Hi Brian, > > > > Thanks for the detail expression. > > > > On Sun, 13 Oct 2024 16:19:31 -0600 > > Brian Inglis wrote: > > >

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

On Mon, 14 Oct 2024 14:29:58 +0900 Takashi Yano wrote: > Hi Brian, > > Thanks for the detail expression. > > On Sun, 13 Oct 2024 16:19:31 -0600 > Brian Inglis wrote: > > On 2024-10-13 14:06, Takashi Yano via Cygwin wrote: > > > Hi Brian > > > > >

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

Hi Brian, Thanks for the detail expression. On Sun, 13 Oct 2024 16:19:31 -0600 Brian Inglis wrote: > On 2024-10-13 14:06, Takashi Yano via Cygwin wrote: > > Hi Brian > > > > On Sun, 13 Oct 2024 10:41:58 -0600 > > Brian Inglis wrote: > >> On 2024-10-12

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

Hi Brian On Sun, 13 Oct 2024 10:41:58 -0600 Brian Inglis wrote: > On 2024-10-12 17:14, Takashi Yano via Cygwin wrote: > > Hi Brian, > > > > On Tue, 8 Oct 2024 10:37:14 -0600 > > Brian Inglis wrote: > >> On 2024-10-08 10:14, Brian Inglis via Cygwin wrote: >

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

On Sun, 13 Oct 2024 11:55:46 +0200 Christian Franke wrote: > Takashi Yano via Cygwin wrote: > > Hi Brian, > > > > On Tue, 8 Oct 2024 10:37:14 -0600 > > Brian Inglis wrote: > >> On 2024-10-08 10:14, Brian Inglis via Cygwin wrote: > >>> On 2024-10-08

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

Hi Brian, On Tue, 8 Oct 2024 10:37:14 -0600 Brian Inglis wrote: > On 2024-10-08 10:14, Brian Inglis via Cygwin wrote: > > On 2024-10-08 05:20, Takashi Yano via Cygwin wrote: > >> On Mon, 7 Oct 2024 15:11:52 +0200 > >> Christian Franke wrote: > >

Re: cygwin 3.5.4-1: signal handling destroys 'long double' values

On Mon, 7 Oct 2024 15:11:52 +0200 Christian Franke wrote: > $ gcc -o sigtest -O2 sigtest.c > > $ ./sigtest > out.txt > (press ^C 42x :-) > > $ sort out.txt | uniq -c >   3 x = 0x1.23456789p+0, y = -nan, d = -nan >   6 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = -nan > 33 x = 0x1

Re: Updated: mintty 3.7.5

On Mon, 23 Sep 2024 10:28:02 +0200 Thomas Wolff wrote: > Am 23.09.2024 um 08:15 schrieb Takashi Yano via Cygwin: > > Hi Thomas, > > > > On Tue, 17 Sep 2024 10:06:36 +0200 > > Thomas Wolff wrote: > >> I have uploaded mintty 3.7.5 with the following changes:

Re: Updated: mintty 3.7.5

Hi Thomas, On Tue, 17 Sep 2024 10:06:36 +0200 Thomas Wolff wrote: > I have uploaded mintty 3.7.5 with the following changes: > > Highlights >   * Box Drawing characters (U+2500..U+257F) are self-drawn (#935, #1119). >   * Tabs can be reordered via user-definable functions (#1283). >   * Emoji

Re: grepping a large file through a pipe takes eons

On Sat, 31 Aug 2024 09:59:11 -0600 Jim Reisert AD1C wrote: > Something has changed in the last month or two. I have a very large > file I am trying to grep (465 MB): > > -rwxrw+ 1 jjrei jjrei 465092052 Aug 31 09:39 all_spots.txt > > > If I grep for something near the end of the file, the re

Re: cygwin application on MsTerminal, enabling win32-raw-mode results in runway memory/CPU usage.

On Sat, 31 Aug 2024 14:57:07 +0800 Adamyg Mob wrote: > I raised the same question under: > https://github.com/microsoft/terminal/issues/17824 Thanks! > *cons_master_thread() should *possibly maintain a local key cache and not > push back events. This needs much modification for the cygwin consol

Re: cygwin application on MsTerminal, enabling win32-raw-mode results in runway memory/CPU usage.

On Sat, 31 Aug 2024 14:20:04 +0900 Takashi Yano wrote: > Thanks for the pointer. Unfortunately, the document does not mention > about the behaviour of WriteConsoleInput() in the win32-inpu-mode. > > I expected that ReadConsoleInput() returns the INPUT_RECORDS which > WriteConsoleInput() sends. How

Re: cygwin application on MsTerminal, enabling win32-raw-mode results in runway memory/CPU usage.

Thanks for the pointer. Unfortunately, the document does not mention about the behaviour of WriteConsoleInput() in the win32-inpu-mode. I expected that ReadConsoleInput() returns the INPUT_RECORDS which WriteConsoleInput() sends. However, that does not seem true in this mode. On Sat, 31 Aug 2024

Re: cygwin application on MsTerminal, enabling win32-raw-mode results in runway memory/CPU usage.

On Fri, 30 Aug 2024 19:56:34 +0800 Adamyg Mob wrote: > Cygwin: CYGWIN_NT-10.0-19045 WEED3 3.5.4-1.x86_64 2024-08-25 16:52 UTC > x86_64 Cygwin > Windows Terminal version: 1.20.11781.0 > Windows build number: 10.0.19045.4780 > > When running a cygwin64 based terminal application under a MsTerminal

Re: Need help in getting the Cygwin 2.8.0 and 2.8.1 sources packages

On Mon, 26 Aug 2024 07:25:55 + "Krishna, Chaitra via Cygwin" wrote: > In 2017, we qualified our programs using Cygwin 2.8.1. Unfortunately, we no > longer have the source code packages and have been unable to locate them > online. Could you please assist us by providing any links, sites, or

Re: trouble with sshpass unmaintained

On Sun, 04 Aug 2024 04:34:24 + Jim McNamara wrote: > This commmand doesnt seem to work: > > sshpass -p 'your_password' rsync -avvv -e 'ssh -4 -vvv -o > StrictHostKeyChecking=no -o PreferredAuthentications=password -o > PubkeyAuthentication=no -p ' /cygdrive/c/cygwin64/home/myuser1/shared

Re: Updated: mingw64-{i686,x86_64}-gcc-12.4.0-1

On Sun, 04 Aug 2024 21:50:40 +0200 ASSI wrote: > The mingw64 cross compilers have been updated for both architectures to > the latest upstream release version of the gcc-11 branch: > > mingw64-i686-gcc-12.4.0-1-src > mingw64-i686-gcc-core-12.4.0-1 > mingw64-i686-gcc-debuginfo-12.4.0-1 > mingw6

Re: no sshd in package for openssh

On Wed, 31 Jul 2024 19:16:26 + Jim McNamara wrote: > I am running into a little difficulty with openssh can you please assist ? > > thanks jim > > ./cygrunsrv --install sshd -d "Cygwin SSHD" -p /usr/bin/sshd -a "-D" > ./cygrunsrv: Given path doesn't point to a valid executable > Try `./cygru

Re: Updated: gcc-12.4.0-3

On Mon, 29 Jul 2024 23:02:17 +0900 Takashi Yano wrote: > On Mon, 29 Jul 2024 07:18:53 +0200 > ASSI wrote: > > Additionally, a new option '-mno-align-vector-insn' has been implemented > > (following the lead of MSys2 and using a patch by Kai Tietz) to enable > > an easier (more targeted) workaround

Re: Updated: gcc-12.4.0-3

On Mon, 29 Jul 2024 07:18:53 +0200 ASSI wrote: > Additionally, a new option '-mno-align-vector-insn' has been implemented > (following the lead of MSys2 and using a patch by Kai Tietz) to enable > an easier (more targeted) workaround for the underlying stack data > alignment problem when passing ve

Re: Parse output of "net use", but language varies - force language for "net use"?

On Sun, 21 Jul 2024 05:57:10 +0200 Thomas Wolff wrote: > Am 21.07.2024 um 01:54 schrieb Takashi Yano via Cygwin: > > On Sat, 20 Jul 2024 15:44:17 +0200 > > Mark Liam Brown wrote: > >> I am trying to parse the output of "net use" in a bash script, but hit > &g

Re: Parse output of "net use", but language varies - force language for "net use"?

On Sat, 20 Jul 2024 15:44:17 +0200 Mark Liam Brown wrote: > I am trying to parse the output of "net use" in a bash script, but hit > a roadblock: > The output of "net use" changes with the language of the system > (English, Danish, French, ...), so parsing becomes nearly impossible > > How can I f

Re: cygwin application hangs on closing console

On Fri, 12 Jul 2024 14:33:31 +0200 Johannes Khoshnazar-Thoma wrote: > Am 03.07.24 um 16:09 schrieb Takashi Yano: > > On Tue, 2 Jul 2024 19:45:15 +0900 > > Takashi Yano wrote: > > I'll submit a patch for that and push it shortly. > > > Thank you so much for the fix. I built a cygwin1.dll containing

Re: SIGALRM is not interrupting a blocking write to a pipe

On Mon, 1 Jul 2024 20:43:28 +0900 Takashi Yano wrote: > On Mon, 1 Jul 2024 20:40:38 +0900 > Takashi Yano wrote: > > On Mon, 6 May 2024 23:01:49 +0300 > > ilya Basin wrote: > > > I need your help with troubleshooting an issue with "pv": > > > https://codeberg.org/a-j-wood/pv/issues/87 > > > > > >

Re: cygwin application hangs on closing console

On Tue, 2 Jul 2024 19:45:15 +0900 Takashi Yano wrote: > On Mon, 1 Jul 2024 22:20:20 +0900 > Takashi Yano wrote: > > On Mon, 1 Jul 2024 13:47:56 +0200 > > Johannes Khoshnazar-Thoma wrote: > > > Note that the hang does not happen when just running cygwin > > > applications via terminal windows (like

Re: cygwin application hangs on closing console

On Mon, 1 Jul 2024 22:20:20 +0900 Takashi Yano wrote: > On Mon, 1 Jul 2024 13:47:56 +0200 > Johannes Khoshnazar-Thoma wrote: > > Note that the hang does not happen when just running cygwin > > applications via terminal windows (like cmd, powershell and > > MinTTY). It triggers however when a cygwin

Re: cygwin application hangs on closing console

On Mon, 1 Jul 2024 13:47:56 +0200 Johannes Khoshnazar-Thoma wrote: > Could you maybe point to the place in the cygwin (winsup) > source code where the minor is allocated? As for console, fhandler_console::set_unit() does that. -- Takashi Yano -- Problem reports: https://cygwin.com/proble

Re: cygwin application hangs on closing console

On Mon, 1 Jul 2024 13:47:56 +0200 Johannes Khoshnazar-Thoma wrote: > Note that the hang does not happen when just running cygwin > applications via terminal windows (like cmd, powershell and > MinTTY). It triggers however when a cygwin application is > run both as a service (I think as SYSTEM accou

Re: SIGALRM is not interrupting a blocking write to a pipe

On Mon, 1 Jul 2024 20:40:38 +0900 Takashi Yano wrote: > On Mon, 6 May 2024 23:01:49 +0300 > ilya Basin wrote: > > I need your help with troubleshooting an issue with "pv": > > https://codeberg.org/a-j-wood/pv/issues/87 > > > > This app uses SIGALRM to interrupt a blocking write to STDOUT and read

  1   2   3   4   5   6   >