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

[Takashi Yano via Cygwin]

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 183
> 321 [main] sh 1280 dofork: child 1288 - died waiting for dll loading, 
> errno 11
> /usr/bin/sh: fork: retry: Resource temporarily unavailable
> 
> Any ideas about this?
> 
> For reference, our build instructions are here: 
> https://wiki.documentfoundation.org/Development/BuildingOnWindows

Thanks for the report. Sorry for very late responce.

Supposedly, this problem has been fixed by the patch:
https://cygwin.com/pipermail/cygwin-patches/2024q4/012842.html

The problem is caused by very complecated mechanism, so it was
hard to reproduce the problem.

I could not successfully prepare build environment for LibreOffice,
therefore, I don't test this patch with building LibreOffice,
however, I hope this fixes that.

I would appriciate if you could test cygwin 3.6.0-0.216.g04f386e9af99 (Test)
or later.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

Hi Brian,

On Mon, 14 Oct 2024 15:38:22 +0900
Takashi Yano wrote:
> 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:
> > > > 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 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:
> > > > >>>>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> > > > >>>>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> > > > >>>>>>>
> > > > >>>>>>> The problem also occurs if compiled without -O2, but less 
> > > > >>>>>>> often. No
> > > > >>>>>>> problem occurs if compiled with -DWORKS which suggests that 
> > > > >>>>>>> only 'long
> > > > >>>>>>> double' is affected.
> > > > >>>>>>
> > > > >>>>>> Thanks for the report. I looked into this problem and might find 
> > > > >>>>>> the
> > > > >>>>>> cause. It seems due to a bug of scripts/gendef. It generates 
> > > > >>>>>> signal
> > > > >>>>>> handler caller (sigfe.s) which stores/restores the registers.
> > > > >>>>>>
> > > > >>>>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> > > > >>>>>> instruction,
> > > > >>>>>> however, fninit instruction destroys some status registers in 
> > > > >>>>>> FPU (x87).
> > > > >>>>>>
> > > > >>>>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and 
> > > > >>>>>> fninit.
> > > > >>>>>> However, I'm not familiar with x87 instructions, so I may 
> > > > >>>>>> overlook
> > > > >>>>>> something.
> > > > >>>>>>
> > > > >>>>>> Could anyone expert of x87 instructions and sigfe stuff give some
> > > > >>>>>> comments?
> > > > >>>>>
> > > > >>>>> AIUI x87 FP handling is outdated and mainly unused on current 
> > > > >>>>> systems, as
> > > > >>>>> current systems do more and use more than the legacy x87 
> > > > >>>>> instructions and stack.
> > > > >>>>>
> > > > >>>>> See https://en.cppreference.com/w/c/numeric/fenv and related docs 
> > > > >>>>> for more
> > > > >>>>> modern approaches.
> > > > >>>>>
> > > > >>>>> You would have to look into the AMD/Intel/IEEE docs for lower 
> > > > >>>>> level details.
> > > > >>>>
> > > > >>>> This is basically what ISTR:
> > > > >>>>
> > > > >>>> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/ration

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

[Takashi Yano via Cygwin]

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() 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 warning on too many locks and returns success. It
> >> should not print a warning and fail with ENOLCK instead.
> >>
> >> Testcase for both:
> >>
> >> $ uname -r
> >> 3.5.4-1.x86_64
> >>
> >> $ cat locktest.c
> >> #include 
> >> #include 
> >> #include 
> >>
> >> static int lock_at(int fd, int off, int size)
> >> {
> >>     if (lseek(fd, off, SEEK_SET) < 0) {
> >>       perror("lseek"); return -1;
> >>     }
> >>     printf("\rlock %d-%d\n", off, off + size - 1); fflush(stdout);
> >>     if (lockf(fd, F_LOCK, size) < 0) {
> >>       perror("lock"); return -1;
> >>     }
> >>     return 0;
> >> }
> >>
> >> int main(int argc, char **argv)
> >> {
> >>     int fd = open("locktest.tmp", O_RDWR|O_CREAT, 0666);
> >>     if (fd < 0) {
> >>       perror("open"); return 1;
> >>     }
> >>
> >>     if (argc == 1) {
> >>       lock_at(fd, 0, 2);
> >>       lock_at(fd, 2, 2);
> >>       lock_at(fd, 1, 2);
> >>     }
> >>     else {
> >>       for (int i = 0; i < 914; i++)
> >>     if (lock_at(fd, i, 1))
> >>       return 1;
> >>     }
> >>     printf("\rdone\n");
> >>     return 0;
> >> }
> >>
> >> $ gcc -o locktest locktest.c
> >>
> >> $ ./locktest
> >> lock 0-1
> >> lock 2-3
> >> lock 1-2
> >>        1 [main] locktest 44864 C:\cygwin64\tmp\locktest.exe: \
> >>      *** fatal error - NtCreateEvent(lock): 0xC035\
> >>      Hangup
> >>
> >> $ ./locktest loop
> >> lock 0-0
> >> lock 1-1
> >> lock 2-2
> >> lock 3-3
> >> ...
> >> lock 909-909
> >> lock 910-910
> >> lock 911-911
> >>     0 [main] locktest 44865 inode_t::get_all_locks_list: \
> >>       Warning, can't handle more than 910 locks per file.
> >> lock 912-912
> >>       727 [main] locktest 44865 inode_t::get_all_locks_list: \
> >>       Warning, can't handle more than 910 locks per file.
> >> lock 913-913
> >>      1329 [main] locktest 44865 inode_t::get_all_locks_list: \
> >>       Warning, can't handle more than 910 locks per file.
> >> done
> >>
> >> There is possibly also an off-by-one error as the 912'th lockf() prints
> >> the first warning.
> > Thanks for the report.
> > I looked into the problems, and considered how to fix them.
> >
> > Could you please try the experimental patch attached?
> 
> 
> Works as expected with both 'locktest.exe' and 'stress-ng --lockf ...'.

Thanks for testing!

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 warning on too many locks and returns success. It 
> should not print a warning and fail with ENOLCK instead.
> 
> Testcase for both:
> 
> $ uname -r
> 3.5.4-1.x86_64
> 
> $ cat locktest.c
> #include 
> #include 
> #include 
> 
> static int lock_at(int fd, int off, int size)
> {
>    if (lseek(fd, off, SEEK_SET) < 0) {
>      perror("lseek"); return -1;
>    }
>    printf("\rlock %d-%d\n", off, off + size - 1); fflush(stdout);
>    if (lockf(fd, F_LOCK, size) < 0) {
>      perror("lock"); return -1;
>    }
>    return 0;
> }
> 
> int main(int argc, char **argv)
> {
>    int fd = open("locktest.tmp", O_RDWR|O_CREAT, 0666);
>    if (fd < 0) {
>      perror("open"); return 1;
>    }
> 
>    if (argc == 1) {
>      lock_at(fd, 0, 2);
>      lock_at(fd, 2, 2);
>      lock_at(fd, 1, 2);
>    }
>    else {
>      for (int i = 0; i < 914; i++)
>    if (lock_at(fd, i, 1))
>      return 1;
>    }
>    printf("\rdone\n");
>    return 0;
> }
> 
> $ gcc -o locktest locktest.c
> 
> $ ./locktest
> lock 0-1
> lock 2-3
> lock 1-2
>       1 [main] locktest 44864 C:\cygwin64\tmp\locktest.exe: \
>     *** fatal error - NtCreateEvent(lock): 0xC035\
>     Hangup
> 
> $ ./locktest loop
> lock 0-0
> lock 1-1
> lock 2-2
> lock 3-3
> ...
> lock 909-909
> lock 910-910
> lock 911-911
>    0 [main] locktest 44865 inode_t::get_all_locks_list: \
>      Warning, can't handle more than 910 locks per file.
> lock 912-912
>      727 [main] locktest 44865 inode_t::get_all_locks_list: \
>      Warning, can't handle more than 910 locks per file.
> lock 913-913
>     1329 [main] locktest 44865 inode_t::get_all_locks_list: \
>      Warning, can't handle more than 910 locks per file.
> done
> 
> There is possibly also an off-by-one error as the 912'th lockf() prints 
> the first warning.

Thanks for the report.
I looked into the problems, and considered how to fix them.

Could you please try the experimental patch attached?

-- 
Takashi Yano 
diff --git a/winsup/cygwin/flock.cc b/winsup/cygwin/flock.cc
index 0f1efa01d..f99b7f538 100644
--- a/winsup/cygwin/flock.cc
+++ b/winsup/cygwin/flock.cc
@@ -297,6 +297,7 @@ class inode_t
 HANDLE  i_dir;
 HANDLE  i_mtx;
 uint32_ti_cnt;/* # of threads referencing this instance. */
+uint32_tlock_cnt;
 
   public:
 inode_t (dev_t dev, ino_t ino);
@@ -321,6 +322,7 @@ class inode_t
 void unlock_and_remove_if_unused ();
 
 lockf_t *get_all_locks_list ();
+uint32_t get_lock_count () { return lock_cnt; };
 
 bool del_my_locks (long long id, HANDLE fhdl);
 };
@@ -503,7 +505,8 @@ inode_t::get (dev_t dev, ino_t ino, bool create_if_missing, 
bool lock)
 }
 
 inode_t::inode_t (dev_t dev, ino_t ino)
-: i_lockf (NULL), i_all_lf (NULL), i_dev (dev), i_ino (ino), i_cnt (0L)
+: i_lockf (NULL), i_all_lf (NULL), i_dev (dev), i_ino (ino), i_cnt (0L),
+  lock_cnt (0)
 {
   HANDLE parent_dir;
   WCHAR name[48];
@@ -586,6 +589,7 @@ inode_t::get_all_locks_list ()
   BOOLEAN restart = TRUE;
   bool last_run = false;
   lockf_t newlock, *lock = i_all_lf;
+  int cnt = 0;
 
   PDIRECTORY_BASIC_INFORMATION dbi_buf = (PDIRECTORY_BASIC_INFORMATION)
 tp.w_get ();
@@ -610,17 +614,16 @@ inode_t::get_all_locks_list ()
  dbi->ObjectName.Buffer[LOCK_OBJ_NAME_LEN] = L'\0';
  if (!newlock.from_obj_name (this, &i_all_lf, dbi->ObjectName.Buffer))
continue;
- if (lock - i_all_lf >= MAX_LOCKF_CNT)
-   {
- system_printf ("Warning, can't handle more than %d locks per 
file.",
-MAX_LOCKF_CNT);
- break;
-   }
+ if (lock - i_all_lf > MAX_LOCKF_CNT)
+   api_fatal ("Can't handle more than %d locks per file.",
+  MAX_LOCKF_CNT);
  if (lock > i_all_lf)
lock[-1].lf_next = lock;
  new (lock++) lockf_t (newlock);
+ cnt++;
}
 }
+  lock_cnt = cnt;
   /* If no lock has been found, return NULL. */
   if (lock == i_all_lf)
 return NULL;
@@ -1349,6 +1352,10 @@ lf_setlock (lockf_t *lock, inode_t *node, lockf_t 
**clean, HANDLE fhdl)
   prev = head;
   block = *head;
   needtolink = 1;
+
+  if (node->get_lock_count () + 2 > MAX_LOCKF_CNT)
+return ENOLCK;
+
   for (;;)
 {
   ovcase = lf_findoverlap (block, lock, SELF, &prev, &overlap);
@@ -1446,23 +1453,22 @@ lf_setlock (lockf_t *lock, inode_t *node, lockf_t 
**clean, HANDLE fhdl)
  prev = &lock->lf_next;
  lf_wakelock (overlap, fhdl);
  overlap->create_lock_obj ();
- lock->create_lock_obj ();
- needtolink = 0;
  continue;
 

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

[Takashi Yano via Cygwin]

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 cygwin1.dll.
> > Windows searches .dll in the current directory first.

Sorry, Windows searches .dll in the directory where the
.exe is located first. Then searches the current directory
second. After that, the directories in $PATH are searched.

> I understand. Seems like a bug as "." is not in my path.

Therefore, adding '.' into your path does not help.

> If it is a windows thing, I guess nothing can be done about it :-(


-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Takashi Yano via Cygwin]

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 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

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

[Takashi Yano via Cygwin]

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:
> > >> #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 windows terminal:
> > >> testx one two three
> > >> testx
> > >> one
> > >> two
> > >> three
> > >>
> > >> when run from cygwin bash shell and /cygdrive/k
> > >> jdeifik@epyc-milan-64 /cygdrive/k
> > >> $ testx one two thee
> > >> testx
> > >> one
> > >> two
> > >> thee
> > >>
> > >> when run from cygwin bash shell and /cygdrive/k/pw-crack
> > >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack
> > >> $ testx one two thee
> > >> testx
> > >> one
> > >> two
> > >> thee
> > >>
> > >> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john
> > >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john
> > >> $ !testx
> > >> testx one two thee
> > >> testx
> > >> one
> > >> two
> > >> thee
> > >>
> > >> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john/run
> > >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> > >> $ testx one two thee
> > >>
> > >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> > >> $
> > >> logout
> > > Is drive k: something special, such as network drive?
> > > If so, what kind of network drive is it?
> > No. It is just an internal sata ssd.
> 
> OK. But I cannot reproduce the problem.
> 
> yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
> $ gcc test.c -o testx.exe
> 
> yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
> $ ./testx one two three
> ./testx
> one
> two
> three
> 
> yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
> $
> 
> Could you please check the result of
> find /cygdrive/k -name cygwin1.dll -exec ls -l '{}' \;
> ?

Also please check:
IFS=':'; for a in ${PATH[@]}; do find $a -name cygwin1.dll -exec ls -l '{}' \; 
; done

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 = 0; i < argc; i++)
> >>       printf("%s\n", argv[i]);
> >> }
> >>
> >> compiled with gcc test.c -o testx.exe
> >>
> >> when run from windows terminal:
> >> testx one two three
> >> testx
> >> one
> >> two
> >> three
> >>
> >> when run from cygwin bash shell and /cygdrive/k
> >> jdeifik@epyc-milan-64 /cygdrive/k
> >> $ testx one two thee
> >> testx
> >> one
> >> two
> >> thee
> >>
> >> when run from cygwin bash shell and /cygdrive/k/pw-crack
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack
> >> $ testx one two thee
> >> testx
> >> one
> >> two
> >> thee
> >>
> >> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john
> >> $ !testx
> >> testx one two thee
> >> testx
> >> one
> >> two
> >> thee
> >>
> >> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john/run
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> >> $ testx one two thee
> >>
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> >> $
> >> logout
> > Is drive k: something special, such as network drive?
> > If so, what kind of network drive is it?
> No. It is just an internal sata ssd.

OK. But I cannot reproduce the problem.

yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
$ gcc test.c -o testx.exe

yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
$ ./testx one two three
./testx
one
two
three

yano@HP-Z230 /cygdrive/h/pw-crack/fred_john/run
$

Could you please check the result of
find /cygdrive/k -name cygwin1.dll -exec ls -l '{}' \;
?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 windows terminal:
> testx one two three
> testx
> one
> two
> three
> 
> when run from cygwin bash shell and /cygdrive/k
> jdeifik@epyc-milan-64 /cygdrive/k
> $ testx one two thee
> testx
> one
> two
> thee
> 
> when run from cygwin bash shell and /cygdrive/k/pw-crack
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack
> $ testx one two thee
> testx
> one
> two
> thee
> 
> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john
> $ !testx
> testx one two thee
> testx
> one
> two
> thee
> 
> when run from cygwin bash shell and /cygdrive/k/pw-crack/fred_john/run
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> $ testx one two thee
> 
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> $
> logout

Is drive k: something special, such as network drive?
If so, what kind of network drive is it?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 run it from bash, on my u disk, it works fine:
> >>
> >> jdeifik@epyc-milan-64 /cygdrive/u
> >> $ lines john.conf
> >> c: 131785  w: 21581  l:  4505  LP p:  67  longest l: 292   john.conf
> >>
> >> When I run wc from my k disk it works.
> >> When I run lines from my k disk, it pauses, then logs out:
> >>
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> >> $ wc john.conf
> >>     4505  21585 131785 john.conf
> >>
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> >> $ lines john.conf
> >>
> >> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> >> $
> >> logout
> >>
> >> I thought the behavior odd, so I removed cygwin, and I did a fresh
> >> install today.
> >> The problem still persists.
> >>
> >> I am including the source for lines.cpp, though not all the libraries
> >> needed to build it.
> >>
> >> Any ideas?
> > Please provide full reproducible test case as well as
> > steps to reproduce.
> >
> It is a bit too complicated to have a reproducible test case.
> It does seem very directory dependent.
> /cygdrive/k/pw-crack\fred_john\run\john.conf - when I run lines, it logs out
> /cygdrive/k/pw-crack\fred_john\john.conf - when I run lines, it works 
> successfully.

How can we compile the test case?
Your inhex.cpp cannot be compiled due to many errors, such as
missing local headers.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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: 131785  w: 21581  l:  4505  LP p:  67  longest l: 292   john.conf
> 
> When I run wc from my k disk it works.
> When I run lines from my k disk, it pauses, then logs out:
> 
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> $ wc john.conf
>    4505  21585 131785 john.conf
> 
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> $ lines john.conf
> 
> jdeifik@epyc-milan-64 /cygdrive/k/pw-crack/fred_john/run
> $
> logout
> 
> I thought the behavior odd, so I removed cygwin, and I did a fresh 
> install today.
> The problem still persists.
> 
> I am including the source for lines.cpp, though not all the libraries 
> needed to build it.
> 
> Any ideas?

Please provide full reproducible test case as well as
steps to reproduce.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Takashi Yano via Cygwin]

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:
> > > 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 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:
> > > >>>>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> > > >>>>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> > > >>>>>>>
> > > >>>>>>> The problem also occurs if compiled without -O2, but less often. 
> > > >>>>>>> No
> > > >>>>>>> problem occurs if compiled with -DWORKS which suggests that only 
> > > >>>>>>> 'long
> > > >>>>>>> double' is affected.
> > > >>>>>>
> > > >>>>>> Thanks for the report. I looked into this problem and might find 
> > > >>>>>> the
> > > >>>>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> > > >>>>>> handler caller (sigfe.s) which stores/restores the registers.
> > > >>>>>>
> > > >>>>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> > > >>>>>> instruction,
> > > >>>>>> however, fninit instruction destroys some status registers in FPU 
> > > >>>>>> (x87).
> > > >>>>>>
> > > >>>>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and 
> > > >>>>>> fninit.
> > > >>>>>> However, I'm not familiar with x87 instructions, so I may overlook
> > > >>>>>> something.
> > > >>>>>>
> > > >>>>>> Could anyone expert of x87 instructions and sigfe stuff give some
> > > >>>>>> comments?
> > > >>>>>
> > > >>>>> AIUI x87 FP handling is outdated and mainly unused on current 
> > > >>>>> systems, as
> > > >>>>> current systems do more and use more than the legacy x87 
> > > >>>>> instructions and stack.
> > > >>>>>
> > > >>>>> See https://en.cppreference.com/w/c/numeric/fenv and related docs 
> > > >>>>> for more
> > > >>>>> modern approaches.
> > > >>>>>
> > > >>>>> You would have to look into the AMD/Intel/IEEE docs for lower level 
> > > >>>>> details.
> > > >>>>
> > > >>>> This is basically what ISTR:
> > > >>>>
> > > >>>> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> > > >>>>
> > > >>>> where legacy x87 and MMX registers are not used or preserved on 
> > > >>>> x86_64/amd64, as
> > > >>>> SSE... instructions and XMM registers are used.
> > > >>>
> > > >>> Thanks for the advice. I read throuh the web pages and related 
> > > >>> documents
> > > >>> and made a patch which uses fxsave/fxrstor and 

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

[Takashi Yano via Cygwin]

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
> > > 
> > > 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:
> > >>>>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> > >>>>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> > >>>>>>>
> > >>>>>>> The problem also occurs if compiled without -O2, but less often. No
> > >>>>>>> problem occurs if compiled with -DWORKS which suggests that only 
> > >>>>>>> 'long
> > >>>>>>> double' is affected.
> > >>>>>>
> > >>>>>> Thanks for the report. I looked into this problem and might find the
> > >>>>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> > >>>>>> handler caller (sigfe.s) which stores/restores the registers.
> > >>>>>>
> > >>>>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> > >>>>>> instruction,
> > >>>>>> however, fninit instruction destroys some status registers in FPU 
> > >>>>>> (x87).
> > >>>>>>
> > >>>>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and 
> > >>>>>> fninit.
> > >>>>>> However, I'm not familiar with x87 instructions, so I may overlook
> > >>>>>> something.
> > >>>>>>
> > >>>>>> Could anyone expert of x87 instructions and sigfe stuff give some
> > >>>>>> comments?
> > >>>>>
> > >>>>> AIUI x87 FP handling is outdated and mainly unused on current 
> > >>>>> systems, as
> > >>>>> current systems do more and use more than the legacy x87 instructions 
> > >>>>> and stack.
> > >>>>>
> > >>>>> See https://en.cppreference.com/w/c/numeric/fenv and related docs for 
> > >>>>> more
> > >>>>> modern approaches.
> > >>>>>
> > >>>>> You would have to look into the AMD/Intel/IEEE docs for lower level 
> > >>>>> details.
> > >>>>
> > >>>> This is basically what ISTR:
> > >>>>
> > >>>> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> > >>>>
> > >>>> where legacy x87 and MMX registers are not used or preserved on 
> > >>>> x86_64/amd64, as
> > >>>> SSE... instructions and XMM registers are used.
> > >>>
> > >>> Thanks for the advice. I read throuh the web pages and related documents
> > >>> and made a patch which uses fxsave/fxrstor and xsave/xrstror to
> > >>> cygwin-patc...@cygwin.com mailing list.
> > >>> https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html
> > >>>
> > >>> Is this as you intended?
> > >>
> > >> That seems to be the preferred approach now, as long as you can correctly
> > >> determine adequate space for fxsave and xsave, given the varying feature 
> > >> sets,
> > >> register counts, and register sizes of recent processors:
> &g

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

[Takashi Yano via Cygwin]

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 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:
> >>>>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> >>>>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> >>>>>>>
> >>>>>>> The problem also occurs if compiled without -O2, but less often. No
> >>>>>>> problem occurs if compiled with -DWORKS which suggests that only 'long
> >>>>>>> double' is affected.
> >>>>>>
> >>>>>> Thanks for the report. I looked into this problem and might find the
> >>>>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> >>>>>> handler caller (sigfe.s) which stores/restores the registers.
> >>>>>>
> >>>>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> >>>>>> instruction,
> >>>>>> however, fninit instruction destroys some status registers in FPU 
> >>>>>> (x87).
> >>>>>>
> >>>>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and 
> >>>>>> fninit.
> >>>>>> However, I'm not familiar with x87 instructions, so I may overlook
> >>>>>> something.
> >>>>>>
> >>>>>> Could anyone expert of x87 instructions and sigfe stuff give some
> >>>>>> comments?
> >>>>>
> >>>>> AIUI x87 FP handling is outdated and mainly unused on current systems, 
> >>>>> as
> >>>>> current systems do more and use more than the legacy x87 instructions 
> >>>>> and stack.
> >>>>>
> >>>>> See https://en.cppreference.com/w/c/numeric/fenv and related docs for 
> >>>>> more
> >>>>> modern approaches.
> >>>>>
> >>>>> You would have to look into the AMD/Intel/IEEE docs for lower level 
> >>>>> details.
> >>>>
> >>>> This is basically what ISTR:
> >>>>
> >>>> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> >>>>
> >>>> where legacy x87 and MMX registers are not used or preserved on 
> >>>> x86_64/amd64, as
> >>>> SSE... instructions and XMM registers are used.
> >>>
> >>> Thanks for the advice. I read throuh the web pages and related documents
> >>> and made a patch which uses fxsave/fxrstor and xsave/xrstror to
> >>> cygwin-patc...@cygwin.com mailing list.
> >>> https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html
> >>>
> >>> Is this as you intended?
> >>
> >> That seems to be the preferred approach now, as long as you can correctly
> >> determine adequate space for fxsave and xsave, given the varying feature 
> >> sets,
> >> register counts, and register sizes of recent processors:
> >> sse/2/3/4.1/4.2/4a/5/ssse3 avx2/512 128/256/512 bits X/Y/ZMM registers.
> > 
> > Thanks for checking.
> > 
> > According to https://cdrdv2.intel.com/v1/dl/getContent/671110 ,
> > fxsave uses 512 bytes fixed length memory to save the current
> > state of the x87 FPU, MMX technology, XMM, and MXCSR registers.
> > 
> > The patch allocates 0x238 bytes:
> >   0x200 (512 bytes): fxsave area
> >   0x008 (  8 bytes): for 16-byte alignment
>

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

[Takashi Yano via Cygwin]

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:
> >>> On 2024-10-08 05:20, Takashi Yano via Cygwin wrote:
> >>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> >>>>>
> >>>>> The problem also occurs if compiled without -O2, but less often. No
> >>>>> problem occurs if compiled with -DWORKS which suggests that only 'long
> >>>>> double' is affected.
> >>>>
> >>>> Thanks for the report. I looked into this problem and might find the
> >>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> >>>> handler caller (sigfe.s) which stores/restores the registers.
> >>>>
> >>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> >>>> instruction,
> >>>> however, fninit instruction destroys some status registers in FPU (x87).
> >>>>
> >>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit.
> >>>> However, I'm not familiar with x87 instructions, so I may overlook
> >>>> something.
> >>>>
> >>>> Could anyone expert of x87 instructions and sigfe stuff give some
> >>>> comments?
> >>>
> >>> AIUI x87 FP handling is outdated and mainly unused on current systems, as
> >>> current systems do more and use more than the legacy x87 instructions and 
> >>> stack.
> >>>
> >>> See https://en.cppreference.com/w/c/numeric/fenv and related docs for more
> >>> modern approaches.
> >>>
> >>> You would have to look into the AMD/Intel/IEEE docs for lower level 
> >>> details.
> >>
> >> This is basically what ISTR:
> >>
> >> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> >>
> >> where legacy x87 and MMX registers are not used or preserved on 
> >> x86_64/amd64, as
> >> SSE... instructions and XMM registers are used.
> > 
> > Thanks for the advice. I read throuh the web pages and related documents
> > and made a patch which uses fxsave/fxrstor and xsave/xrstror to
> > cygwin-patc...@cygwin.com mailing list.
> > https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html
> > 
> > Is this as you intended?
> 
> That seems to be the preferred approach now, as long as you can correctly 
> determine adequate space for fxsave and xsave, given the varying feature 
> sets, 
> register counts, and register sizes of recent processors: 
> sse/2/3/4.1/4.2/4a/5/ssse3 avx2/512 128/256/512 bits X/Y/ZMM registers.

Thanks for checking.

According to https://cdrdv2.intel.com/v1/dl/getContent/671110 ,
fxsave uses 512 bytes fixed length memory to save the current
state of the x87 FPU, MMX technology, XMM, and MXCSR registers.

The patch allocates 0x238 bytes:
 0x200 (512 bytes): fxsave area
 0x008 (  8 bytes): for 16-byte alignment
 0x010 ( 16 bytes): work area
 0x020 ( 32 bytes): reserved for later processing

According to https://cdrdv2.intel.com/v1/dl/getContent/671436 ,
cpuid instruction with eax=0dh and ecs=00h returns the maximum
size required by xsave in ebx. So the patch allocates:
ebx + 0x048 bytes.
 0x018 ( 24 bytes): for 64-byte alignment
 0x010 ( 16 bytes): work area
 0x020 ( 32 bytes): reserved for later processing

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 05:20, Takashi Yano via Cygwin wrote:
> >>>> 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> >>>>>
> >>>>> The problem also occurs if compiled without -O2, but less often. No
> >>>>> problem occurs if compiled with -DWORKS which suggests that only 'long
> >>>>> double' is affected.
> >>>> Thanks for the report. I looked into this problem and might find the
> >>>> cause. It seems due to a bug of scripts/gendef. It generates signal
> >>>> handler caller (sigfe.s) which stores/restores the registers.
> >>>>
> >>>> In sigdelayed, control word is stored/restored by fnstcw/fldcw 
> >>>> instruction,
> >>>> however, fninit instruction destroys some status registers in FPU (x87).
> >>>>
> >>>> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit.
> >>>> However, I'm not familiar with x87 instructions, so I may overlook
> >>>> something.
> >>>>
> >>>> Could anyone expert of x87 instructions and sigfe stuff give some
> >>>> comments?
> >>> AIUI x87 FP handling is outdated and mainly unused on current systems, as
> >>> current systems do more and use more than the legacy x87 instructions and 
> >>> stack.
> >>>
> >>> See https://en.cppreference.com/w/c/numeric/fenv and related docs for more
> >>> modern approaches.
> >>>
> >>> You would have to look into the AMD/Intel/IEEE docs for lower level 
> >>> details.
> >> This is basically what ISTR:
> >>
> >> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> >>
> >> where legacy x87 and MMX registers are not used or preserved on 
> >> x86_64/amd64, as
> >> SSE... instructions and XMM registers are used.
> > Thanks for the advice. I read throuh the web pages and related documents
> > and made a patch which uses fxsave/fxrstor and xsave/xrstror to
> > cygwin-patc...@cygwin.com mailing list.
> > https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html
> 
> The patch fixes the testcases from my original post on a CPU with XSAFE 
> support and also if usage of FXSAVE if forced by this hack:
> 
>      movl    \$1,%eax
>      cpuid
> -   andl    \$0x0400,%ecx # xsave available?
> +   andl    \$0x,%ecx # xsave available?
>      jnz 1f

Thanks for testing!

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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:
> >>> $ 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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> >>>
> >>> The problem also occurs if compiled without -O2, but less often. No
> >>> problem occurs if compiled with -DWORKS which suggests that only 'long
> >>> double' is affected.
> >>
> >> Thanks for the report. I looked into this problem and might find the
> >> cause. It seems due to a bug of scripts/gendef. It generates signal
> >> handler caller (sigfe.s) which stores/restores the registers.
> >>
> >> In sigdelayed, control word is stored/restored by fnstcw/fldcw instruction,
> >> however, fninit instruction destroys some status registers in FPU (x87).
> >>
> >> I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit.
> >> However, I'm not familiar with x87 instructions, so I may overlook
> >> something.
> >>
> >> Could anyone expert of x87 instructions and sigfe stuff give some
> >> comments?
> > 
> > AIUI x87 FP handling is outdated and mainly unused on current systems, as 
> > current systems do more and use more than the legacy x87 instructions and 
> > stack.
> > 
> > See https://en.cppreference.com/w/c/numeric/fenv and related docs for more 
> > modern approaches.
> > 
> > You would have to look into the AMD/Intel/IEEE docs for lower level details.
> 
> This is basically what ISTR:
> 
> https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html
> 
> where legacy x87 and MMX registers are not used or preserved on x86_64/amd64, 
> as 
> SSE... instructions and XMM registers are used.

Thanks for the advice. I read throuh the web pages and related documents
and made a patch which uses fxsave/fxrstor and xsave/xrstror to
cygwin-patc...@cygwin.com mailing list.
https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html

Is this as you intended?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
> 
> The problem also occurs if compiled without -O2, but less often. No 
> problem occurs if compiled with -DWORKS which suggests that only 'long 
> double' is affected.

Thanks for the report. I looked into this problem and might find the
cause. It seems due to a bug of scripts/gendef. It generates signal
handler caller (sigfe.s) which stores/restores the registers.

In sigdelayed, control word is stored/restored by fnstcw/fldcw instruction,
however, fninit instruction destroys some status registers in FPU (x87).

I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit.
However, I'm not familiar with x87 instructions, so I may overlook
something.

Could anyone expert of x87 instructions and sigfe stuff give some
comments?

-- 
Takashi Yano 

-- 
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

Re: Updated: mintty 3.7.5

[Takashi Yano via Cygwin]

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:
> >>
> >> Highlights
> >>     * Box Drawing characters (U+2500..U+257F) are self-drawn (#935, #1119).
> >>     * Tabs can be reordered via user-definable functions (#1283).
> >>     * Emoji width mode (DECSET 2027) to always render emojis in 2-cell 
> >> width.
> >>     * Fix rendering of combined characters in South East Asian scripts
> >> (#1285).
> >>
> >> Unicode and Emoji data
> >>     * Unicode 16.0 update.
> >>
> >> Terminal features
> >>     * Emoji width mode (DECSET 2027) to always render emojis in 2-cell 
> >> width.
> >>     * Dropped deprecated DECSET mode 2027 for terminal reflow.
> >>     * Fix CopyTab=true behaviour (#1281).
> >>
> >> Character encoding
> >>     * Disable GB18030 workaround for cygwin since 3.5 which supports it
> >> natively.
> >>
> >> Font and character rendering
> >>     * Fix rendering of combined characters in South East Asian scripts
> >> (#1285).
> >>     * Fix and enable rendering for geometric Powerline symbols (#979, 
> >> #943).
> >>     * Avoid bottom padding artefacts of double-height self-drawn symbols.
> >>     * Box Drawing characters (U+2500..U+257F) are self-drawn (#935, #1119).
> >>
> >> Mouse and menu handling
> >>     * Allow disabling of mouse menus by clearing Menu* (#1279).
> >>
> >> Window handling
> >>     * Avoid interaction problem of tabbed/non-tabbed windows.
> >>     * Tabs can be reordered via user-definable functions (#1283).
> >>     * Tweak initial window display, mitigate bright flash (#1284).
> >>     * Border style can be set also via config file (#7).
> >>
> >> Configuration
> >>     * New option BoxDrawing (#935, #1119).
> >>     * New user-definable functions tab-left, tab-right to reorder tabbar
> >> (#1283).
> >>     * Setting options Menu* to empty value disables the respective menu
> >> (#1279).
> >>     * Skip config files in $HOME if $HOME does not exist 
> >> (mintty/wsltty#351).
> >>     * New option BorderStyle (#7).
> >>
> >> The homepage is athttp://mintty.github.io/
> >> It also links to the issue tracker.
> > After updating mintty from 3.7.4 to 3.7.5, the frame lines in mocp command
> > in moc (Music on Console) package are not shown correctly. The line chars
> > seem to be drawn, however not shown. Any idea?
> >
> > How to reproduce the problem:
> > (1) Install moc and moc_plugins package.
> > (2) Run mocp
> > (3) Compare screen between 3.7.4 and 3.7.5
> Repeated DEC graphics don't display. An embarrassing bug... Fixed in the
> repository already, I will make a release soon.

I've confirmed the issue has  been fixed in 3.7.6.
Thank you!

-- 
Takashi Yano 

-- 
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

Re: Updated: mintty 3.7.5

[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:
> 
> Highlights
>    * Box Drawing characters (U+2500..U+257F) are self-drawn (#935, #1119).
>    * Tabs can be reordered via user-definable functions (#1283).
>    * Emoji width mode (DECSET 2027) to always render emojis in 2-cell width.
>    * Fix rendering of combined characters in South East Asian scripts
> (#1285).
> 
> Unicode and Emoji data
>    * Unicode 16.0 update.
> 
> Terminal features
>    * Emoji width mode (DECSET 2027) to always render emojis in 2-cell width.
>    * Dropped deprecated DECSET mode 2027 for terminal reflow.
>    * Fix CopyTab=true behaviour (#1281).
> 
> Character encoding
>    * Disable GB18030 workaround for cygwin since 3.5 which supports it
> natively.
> 
> Font and character rendering
>    * Fix rendering of combined characters in South East Asian scripts
> (#1285).
>    * Fix and enable rendering for geometric Powerline symbols (#979, #943).
>    * Avoid bottom padding artefacts of double-height self-drawn symbols.
>    * Box Drawing characters (U+2500..U+257F) are self-drawn (#935, #1119).
> 
> Mouse and menu handling
>    * Allow disabling of mouse menus by clearing Menu* (#1279).
> 
> Window handling
>    * Avoid interaction problem of tabbed/non-tabbed windows.
>    * Tabs can be reordered via user-definable functions (#1283).
>    * Tweak initial window display, mitigate bright flash (#1284).
>    * Border style can be set also via config file (#7).
> 
> Configuration
>    * New option BoxDrawing (#935, #1119).
>    * New user-definable functions tab-left, tab-right to reorder tabbar
> (#1283).
>    * Setting options Menu* to empty value disables the respective menu
> (#1279).
>    * Skip config files in $HOME if $HOME does not exist (mintty/wsltty#351).
>    * New option BorderStyle (#7).
> 
> The homepage is at http://mintty.github.io/
> It also links to the issue tracker.

After updating mintty from 3.7.4 to 3.7.5, the frame lines in mocp command
in moc (Music on Console) package are not shown correctly. The line chars
seem to be drawn, however not shown. Any idea?

How to reproduce the problem:
(1) Install moc and moc_plugins package.
(2) Run mocp
(3) Compare screen between 3.7.4 and 3.7.5

-- 
Takashi Yano 

-- 
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

Re: grepping a large file through a pipe takes eons

[Takashi Yano via Cygwin]

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 results return right 
> away:
> 
> # time grep -n N0FUL all_spots.txt
> 
> 17027336:N0FUL,20240615,20240615,1
> 17027337:N0FUL,20240629,20240629,1
> 
> real0m0.190s
> user0m0.078s
> sys 0m0.078s
> 
> 
> If I pipe the file through cat, grep takes much longer:
> 
> # time cat all_spots.txt | grep -n N0FUL
> 
> 17027336:N0FUL,20240615,20240615,1
> 17027337:N0FUL,20240629,20240629,1
> 
> 
> real1m4.934s
> user0m0.031s
> sys 0m0.124s

Thanks for the report. This seems to be a regression of cygwin 3.5.4.
I'll submit a patch for this issue shortly.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 console code because
the local key cache should be able to access from other process
running in the same console. This needs inter-process-communication
or shared memory.

> Alternatively, from research these pseudo key events have Vk=0/Sc=0 values
> (only char and down are set);  as such peek the console input queue and
> don't process the input stream if detected.

Another simple solution is disabling cons_master_thread in win32-input-mode.
The signalling keys such as Ctrl-C, Ctrl-Z etc. never comes anyway in that
mode.

Now I'm testing this solution.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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. However, that does not seem true in this
> mode.

Moreover, there seems to be no means to determine if win32-input-mode
is enabled or not.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 12:24:46 +0800
Adamyg Mob wrote:
>  *One suspect is the fhandler_console::cons_master_thread (), which
> attempts to mine signals within the input stream; yet it may not handle a
> single key being represented by multiple events.*; furthermore one of the
> few uses of WriteConsoleInput
> Is there any means of disabling the feature for testing?

There is no other means than modifying the source code of cygwin1.dll
and rebuild it. I already tried that and the problem disappeard.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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
> session, with win32-raw-mode "\033[?9001h" enabled,
> after brief input in the application becoming unresponsive and the session
> rapidly consumes all available memory/cpu..
> 
> Test application attached, plus ticket
> https://github.com/microsoft/terminal/issues/17824 contains additional
> information.

Thanks for the report.

Are there any documents for win32-raw-mode "\033[?9001h" ?

I am very puzzled with that WriteConsoleInput() with one event
generates ~15 input events for ReadConsoleInput() in this mode.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 
> repositories where we can download the source packages for Cygwin 2.8.0 and 
> 2.8.1?

git clone https://cygwin.com/git/newlib-cygwin.git --depth 1 -b 
cygwin-2_8_0-release
git clone https://cygwin.com/git/newlib-cygwin.git --depth 1 -b 
cygwin-2_8_1-release

-- 
Takashi Yano 

-- 
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

Re: trouble with sshpass unmaintained

[Takashi Yano via Cygwin]

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/ 
> myuser1@127.0.0.1:/home/myuser1/

Questions:
1) Why did not you provide the error messages you got at all?
2) Why do you specify "-p " to ssh? Did you change the ssh port
   to  from default 22?
3) Why do you specify source and destination that seem to be on the
   same machine?
 /cygdrive/c/cygwin64/home/myuser1/shared/
 myuser1@127.0.0.1:/home/myuser1
   This command try to backup files in /home/myuser1/shared/ to 
   /home/myuser1 which is the upper directory of former one.
   Do you really want to do that?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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
>  mingw64-i686-gcc-fortran-12.4.0-1
>  mingw64-i686-gcc-g++-12.4.0-1
>  mingw64-i686-gcc-objc-12.4.0-1
> 
>  mingw64-x86_64-gcc-12.4.0-1-src
>  mingw64-x86_64-gcc-core-12.4.0-1
>  mingw64-x86_64-gcc-debuginfo-12.4.0-1
>  mingw64-x86_64-gcc-fortran-12.4.0-1
>  mingw64-x86_64-gcc-g++-12.4.0-1
>  mingw64-x86_64-gcc-objc-12.4.0-1

This release does not seem to be applied '-mno-align-vector-insn'
patch. Is this intentional?

-- 
Takashi Yano 

-- 
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

Re: no sshd in package for openssh

[Takashi Yano via Cygwin]

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 `./cygrunsrv --help' for more information.

Generally speaking, You should run ssh-host-config rather than
running cygrunsrv --install manually.

-- 
Takashi Yano 

-- 
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

Re: Updated: gcc-12.4.0-3

[Takashi Yano via Cygwin]

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 for the underlying stack data
> > alignment problem when passing vector datatypes by value (which is due
> > to a conflict with alignment requirements for SEH and remains unsolved
> > upstream).  You can also use '-Wa,-muse-unaligned-vector-move', which is
> > more widely available.
> 
> gcc of MSYS2 enables -mno-align-vector-insn flag by default.
> However gcc 12.4.0-3 does not enable this flag by default.
> 
> Is this intentional?

Ah, I misunderstood.

For MSYS2,
/usr/bin/gcc   : without Kai's patch
/mingw64/bin/gcc   : -mno-align-vector-insn is enabled by default
/mingw32/bin/gcc   : -mno-align-vector-insn is enabled by default

For current cygwin,
/usr/bin/gcc (12.4.0-3)  : -mno-align-vector-insn is disabled by default
/usr/bin/x86_64-w64-mingw32-gcc : without Kai's patch (yet?)
/usr/bin/i686-w64-mingw32-gcc   : without Kai's patch (yet?)

-- 
Takashi Yano 

-- 
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

Re: Updated: gcc-12.4.0-3

[Takashi Yano via Cygwin]

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 vector datatypes by value (which is due
> to a conflict with alignment requirements for SEH and remains unsolved
> upstream).  You can also use '-Wa,-muse-unaligned-vector-move', which is
> more widely available.

gcc of MSYS2 enables -mno-align-vector-insn flag by default.
However gcc 12.4.0-3 does not enable this flag by default.

Is this intentional?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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
> >> 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 force the language used by "net use" to English, even if the
> >> system default language is Danish or French?
> > Did you try
> > chcp.com 437
> That could change the character encoding, for some (older) programs, not
> the language.

You are right. However, in Japanese environment, net use command
output Japanese message on CP932 and English message on CP437.

So, I think that this might change the message language even in
Danish, French or Germany environment.

-- 
Takashi Yano 

-- 
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

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

[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
> 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 force the language used by "net use" to English, even if the
> system default language is Danish or French?

Did you try
chcp.com 437
or something like that?

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

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
> your patch and forwarded it to our client. Tests are running
> since yesterday without any issues. Before after a few minutes
> the console_close() caused (at least) processes to hang for at
> least a few seconds.
> 
> We will keep the tests running over the weekend but I think we
> can assume that the hang in closing console is fixed.

Thanks for testing. If you could continue the test,
it is better to use head of cygwin-3_5-branch.

git clone https://cygwin.com/git/newlib-cygwin.git
cd newlib-cygwin
git switch cygwin-3_5-branch
winsup/autogen.sh
configure
make -j8

Then, copy x86_64-pc-cygwin/winsup/cygwin/new-cygwin1.dll to
your test environment.

> Thank you so much again, just wanted to ask: will you (and
> when) release cygwin DLL 3.5.4 shortly? Could you estimate
> when this will happen? Knowing that would help us in planning
> the next WinDRBD release (with the 3.5.4 cygwin DLL).

This is not under my control. :-)

Corinna, what do you think?
Some important fixes are now ready for 3.5.4. How about releasing
3.5.4 after the pipe fix?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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
> > > 
> > > This app uses SIGALRM to interrupt a blocking write to STDOUT and read 
> > > more data into the buffer.
> > > On Linuxes write() returns 0 after the signal, but on Cygwin even though 
> > > the signal handler is called, the write call does not return, at least 
> > > when writing to a pipe.
> > 
> > What Linux environment you assume? I run the STC below on Debuan GNU/Linux,
> > 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > void handler(int sig)
> > {
> > printf("sig=%d\n", sig);
> > }
> > 
> > int main()
> > {
> > int fd[2];
> > 
> > signal(SIGALRM, handler);
> > pipe(fd);
> > for (;;) {
> > int l = write(fd[1], "A", 1);
> > if (l == 1) {
> > printf("."); fflush(stdout); /* Normal */
> > } else {
> > printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
> > }
> > }
> > }
> > 
> > but,
> > kill -ALRM 
> > does not make output /* Interrupt */ line, but only /* Normal */ line.
> 
> and
> sig=14
> as well.
> 
> > uname -a:
> > Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
> > (2024-05-03) x86_64 GNU/Linux
> > 
> > The behaviour is same with cygwin.

I got it. signal() sets SA_RESTART flag which prevent write()
from interrupt. Without SA_RESTART, I can see the behaviour
difference between linux and cygwin.

Now we are discussing how to fix that problem. Thansk.

P.S.
Attached is the my second STC. The STC without argument behaves
differently on cygwin from linux.

-- 
Takashi Yano 
#include 
#include 
#include 
#include 
#include 
#include 

void handler(int sig)
{
	fprintf(stderr, "sig=%d\n", sig);
}

int main(int argc, char *argv[])
{
	int fd[2] = {0, 1};
	struct sigaction sa = {0,};

	sa.sa_handler = handler;
	if (argc > 1 && atoi(argv[1])) {
		sa.sa_flags = SA_RESTART;
	}
	sigaction(SIGALRM, &sa, NULL);

	if (isatty(1)) {
		pipe(fd);
	}

	for (;;) {
		int l = write(fd[1], "A", 1);
		if (l == 1) {
			fprintf(stderr, "."); fflush(stderr);
		} else {
			fprintf(stderr, "%d: %s\n", l, strerror(errno));
		}
	}
}

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

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 cmd, powershell and
> > > MinTTY). It triggers however when a cygwin application is
> > > run both as a service (I think as SYSTEM account, but I
> > > can ask again) and from a terminal window.
> > 
> > Service process usually does not have console. So I think
> > fhandler_console::open()/close() are not called.
> > 
> > Do you allocate console for your service process somehow?
> 
> I could reproduce your problem by allocating console for
> service process.
> 
> I'll look into the problem. Thanks.

The cause has been clear. As a result, your points and patches
were very spot on.

get_minor() retuns unique number for each console in a session,
but not unique accross sessions. I looked over that point.

This is because EnumWindows(), which is used to look for console
windows, cannot enumerate windows accross sessions. This causes
conflict on shared name between sessions (e.g. sessions of different
users, different services, a service and a user session, etc.).

I'll use GetConsoleWindow() instead of get_minor() to create
shared name.

Thank you very much for finding this problem.
I'll submit a patch for that and push it shortly.

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

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 application is
> > run both as a service (I think as SYSTEM account, but I
> > can ask again) and from a terminal window.
> 
> Service process usually does not have console. So I think
> fhandler_console::open()/close() are not called.
> 
> Do you allocate console for your service process somehow?

I could reproduce your problem by allocating console for
service process.

I'll look into the problem. Thanks.

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

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/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

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 account, but I
> can ask again) and from a terminal window.

Service process usually does not have console. So I think
fhandler_console::open()/close() are not called.

Do you allocate console for your service process somehow?

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 more 
> > data into the buffer.
> > On Linuxes write() returns 0 after the signal, but on Cygwin even though 
> > the signal handler is called, the write call does not return, at least when 
> > writing to a pipe.
> 
> What Linux environment you assume? I run the STC below on Debuan GNU/Linux,
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> void handler(int sig)
> {
>   printf("sig=%d\n", sig);
> }
> 
> int main()
> {
>   int fd[2];
> 
>   signal(SIGALRM, handler);
>   pipe(fd);
>   for (;;) {
>   int l = write(fd[1], "A", 1);
>   if (l == 1) {
>   printf("."); fflush(stdout); /* Normal */
>   } else {
>   printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
>   }
>   }
> }
> 
> but,
> kill -ALRM 
> does not make output /* Interrupt */ line, but only /* Normal */ line.

and
sig=14
as well.

> uname -a:
> Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
> (2024-05-03) x86_64 GNU/Linux
> 
> The behaviour is same with cygwin.

-- 
Takashi Yano 

-- 
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

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

[Takashi Yano via Cygwin]

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 more 
> data into the buffer.
> On Linuxes write() returns 0 after the signal, but on Cygwin even though the 
> signal handler is called, the write call does not return, at least when 
> writing to a pipe.

What Linux environment you assume? I run the STC below on Debuan GNU/Linux,

#include 
#include 
#include 
#include 
#include 
#include 

void handler(int sig)
{
printf("sig=%d\n", sig);
}

int main()
{
int fd[2];

signal(SIGALRM, handler);
pipe(fd);
for (;;) {
int l = write(fd[1], "A", 1);
if (l == 1) {
printf("."); fflush(stdout); /* Normal */
} else {
printf("%d: %s\n", l, strerror(errno)); /* Interrupt */
}
}
}

but,
kill -ALRM 
does not make output /* Interrupt */ line, but only /* Normal */ line.

uname -a:
Linux debian2 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 
(2024-05-03) x86_64 GNU/Linux

The behaviour is same with cygwin.

-- 
Takashi Yano 

-- 
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

Re: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Mon, 1 Jul 2024 17:43:53 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 22:55:22 +0900
> Takashi Yano wrote:
> > On Sun, 30 Jun 2024 20:33:19 +0900
> > jojelino wrote:
> > > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > > Reran cygport --debug upload and command hanging was ssh-add -l!
> > > > 
> > >296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> > > TERM_PROGRAM=mintty
> > >189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> > > TERM_PROGRAM_VERSION=3.7.1
> > > 
> > > I was able to reproduce this problem by entering below command with 
> > > ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> > > spams putc. So, without piping its output to `tee', It would not 
> > > possible track down any cause among lengthy trace output.
> > > 
> > > strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> > > 
> > > In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> > > itself, btw some member of the pgrp may have acquired any of 
> > > synchronization object of some part of cygwin internal when a member 
> > > process of the pgrp did encounter the signal interrupt from `timeout'. 
> > > In my case it was output_mutex of pty.
> > > 
> > >   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
> > >   2701 15224348 [main] mintty 744 
> > > fhandler_pty_master::process_slave_output: bytes read 256
> > >   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
> > >   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> > > write(0x7C780, 1024)
> > >   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
> > >   2084 15226432 [main] mintty 744 
> > > fhandler_pty_master::process_slave_output: returning 256
> > >   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > > output_mutex (0x4C0): waiti
> > > -1 ms
> > >732 9527521 [sig] sh 746 checkstate: child_procs count 2
> > >   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> > > 0x1A005 (wanted 0x1A
> > > ), h 0x16C, m 6, created 0
> > >   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > > output_mutex: acquired
> > > 
> > >   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> > > pty output_mutex (0x4AC):
> > > ting -1 ms
> > > 
> > > And below is a location where `tee' did hang.
> > > 
> > > #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
> > >  ptr=0x7c780, len=)
> > >  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> > > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > > false,
> > > (gdb)  li
> > > 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, 
> > > len);
> > > 1264
> > > 1265  push_process_state process_state (PID_TTYOU);
> > > 1266
> > > 1267  acquire_output_mutex (mutex_timeout);
> > > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > > false,
> > > 1269 get_ttyp (), is_nonblocking ()))
> > > 
> > > 
> > > I ended up prepending two CancelIo call just above of 
> > > acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> > > 
> > >  >  CancelIo(get_ttyp()->to_master());
> > >  >  CancelIo(get_ttyp()->to_master_nat());
> > > acquire_output_mutex (mutex_timeout);
> > > 
> > > Hope it helps
> > 
> > I cannot reproduce the issue.
> > 
> > 1) Which cygwin version do you use?
> > 2) Is this really the same problem with the problem original post reported?
> >(i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)
> 
> I could reproduce this (the problem reported by jojelino) by:
> mintty -e timeout 1 dash -c 'yes  | cat'
> 
> This also occurs with cygwin 3.5.3, so it's another problem than Brian 
> reported.
> 
> This does not occur by:
> mintty -e timeout 1 dash -c 'yes '
> mintty -e timeout 1 tcsh -c 'yes  | cat'
> script /dev/null -c timeout 1 dash -c 'yes  | 
> cat'
> 
> I looked into this probelm and found the cause.
> 
> When the child process (timeout) is terminated, mintty seems to stop reading
> pty master even if yes or cat still alive. (Is this right? >> Thomas)
> (This behaviour seems to be a side efect of patch_319(?) in mintty.)
> 
> If the the pipe used to transfer output from pty slave to pty master is full
> due to lack of master reader, WriteFile() to the pipe is blocked. WriteFile()
> cannot be canceled by cygwin signal, therefore, pty slave hangs.
> 
> I'll submit and push a patch to fix this.
> 
> Thanks for finding this issue. >> jojelino

Please test cygwin-3.6.0-0.145.gc4fb5da27876

Cygwin 3.5.4 will come with this fix.

-- 
Takashi Yano 

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.

Re: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Sun, 30 Jun 2024 22:55:22 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 20:33:19 +0900
> jojelino wrote:
> > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > Reran cygport --debug upload and command hanging was ssh-add -l!
> > > 
> >296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> > TERM_PROGRAM=mintty
> >189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> > TERM_PROGRAM_VERSION=3.7.1
> > 
> > I was able to reproduce this problem by entering below command with 
> > ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> > spams putc. So, without piping its output to `tee', It would not 
> > possible track down any cause among lengthy trace output.
> > 
> > strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> > 
> > In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> > itself, btw some member of the pgrp may have acquired any of 
> > synchronization object of some part of cygwin internal when a member 
> > process of the pgrp did encounter the signal interrupt from `timeout'. 
> > In my case it was output_mutex of pty.
> > 
> >   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
> >   2701 15224348 [main] mintty 744 
> > fhandler_pty_master::process_slave_output: bytes read 256
> >   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
> >   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> > write(0x7C780, 1024)
> >   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
> >   2084 15226432 [main] mintty 744 
> > fhandler_pty_master::process_slave_output: returning 256
> >   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > output_mutex (0x4C0): waiti
> > -1 ms
> >732 9527521 [sig] sh 746 checkstate: child_procs count 2
> >   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> > 0x1A005 (wanted 0x1A
> > ), h 0x16C, m 6, created 0
> >   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> > output_mutex: acquired
> > 
> >   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> > pty output_mutex (0x4AC):
> > ting -1 ms
> > 
> > And below is a location where `tee' did hang.
> > 
> > #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
> >  ptr=0x7c780, len=)
> >  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > false,
> > (gdb)  li
> > 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
> > 1264
> > 1265  push_process_state process_state (PID_TTYOU);
> > 1266
> > 1267  acquire_output_mutex (mutex_timeout);
> > 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> > false,
> > 1269 get_ttyp (), is_nonblocking ()))
> > 
> > 
> > I ended up prepending two CancelIo call just above of 
> > acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> > 
> >  >CancelIo(get_ttyp()->to_master());
> >  >CancelIo(get_ttyp()->to_master_nat());
> >   acquire_output_mutex (mutex_timeout);
> > 
> > Hope it helps
> 
> I cannot reproduce the issue.
> 
> 1) Which cygwin version do you use?
> 2) Is this really the same problem with the problem original post reported?
>(i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)

I could reproduce this (the problem reported by jojelino) by:
mintty -e timeout 1 dash -c 'yes  | cat'

This also occurs with cygwin 3.5.3, so it's another problem than Brian reported.

This does not occur by:
mintty -e timeout 1 dash -c 'yes '
mintty -e timeout 1 tcsh -c 'yes  | cat'
script /dev/null -c timeout 1 dash -c 'yes  | 
cat'

I looked into this probelm and found the cause.

When the child process (timeout) is terminated, mintty seems to stop reading
pty master even if yes or cat still alive. (Is this right? >> Thomas)
(This behaviour seems to be a side efect of patch_319(?) in mintty.)

If the the pipe used to transfer output from pty slave to pty master is full
due to lack of master reader, WriteFile() to the pipe is blocked. WriteFile()
cannot be canceled by cygwin signal, therefore, pty slave hangs.

I'll submit and push a patch to fix this.

Thanks for finding this issue. >> jojelino

-- 
Takashi Yano 

-- 
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

Re: ssh-add -l hangs under cygwin test 3.6.0-0.139.g...

[Takashi Yano via Cygwin]

On Sun, 30 Jun 2024 20:33:19 +0900
jojelino wrote:
> On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > Reran cygport --debug upload and command hanging was ssh-add -l!
> > 
>296   72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0: 
> TERM_PROGRAM=mintty
>189   72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300: 
> TERM_PROGRAM_VERSION=3.7.1
> 
> I was able to reproduce this problem by entering below command with 
> ffmpeg from https://www.gyan.dev/ffmpeg/builds/ , this ffmpeg build 
> spams putc. So, without piping its output to `tee', It would not 
> possible track down any cause among lengthy trace output.
> 
> strace mintty -e /bin/timeout 10 sh -c './ffmpeg -h full|& tee'
> 
> In summary, When `timeout' expires, `timeout' signals SIGHUP to pgrp of 
> itself, btw some member of the pgrp may have acquired any of 
> synchronization object of some part of cygwin internal when a member 
> process of the pgrp did encounter the signal interrupt from `timeout'. 
> In my case it was output_mutex of pty.
> 
>   1565 10693297 [main] timeout 745 kill_pgrp: pid 0, signal 15
>   2701 15224348 [main] mintty 744 
> fhandler_pty_master::process_slave_output: bytes read 256
>   1736 9525442 [sig] sh 746 proc_subproc: args: 4, 1
>   3137 6700294 [main] tee 748 fhandler_pty_slave::write: pty5, 
> write(0x7C780, 1024)
>   1347 9526789 [sig] sh 746 proc_subproc: clear waiting threads
>   2084 15226432 [main] mintty 744 
> fhandler_pty_master::process_slave_output: returning 256
>   1110 6701404 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> output_mutex (0x4C0): waiti
> -1 ms
>732 9527521 [sig] sh 746 checkstate: child_procs count 2
>   3648 10696945 [main] timeout 745 open_shared: name cygpid.724, shared 
> 0x1A005 (wanted 0x1A
> ), h 0x16C, m 6, created 0
>   1055 6702459 [main] tee 748 fhandler_pty_slave::write: (1267): pty 
> output_mutex: acquired
> 
>   2092 15753306 [main] mintty 744 fhandler_pty_master::close: (2095): 
> pty output_mutex (0x4AC):
> ting -1 ms
> 
> And below is a location where `tee' did hang.
> 
> #3  0x7ffd0e408fdf in fhandler_pty_slave::write (this=0x89a10,
>  ptr=0x7c780, len=)
>  at ../../.././winsup/cygwin/fhandler/pty.cc:1268
> 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> false,
> (gdb)  li
> 1263  termios_printf ("pty%d, write(%p, %lu)", get_minor (), ptr, len);
> 1264
> 1265  push_process_state process_state (PID_TTYOU);
> 1266
> 1267  acquire_output_mutex (mutex_timeout);
> 1268  if (!process_opost_output (get_output_handle (), ptr, towrite, 
> false,
> 1269 get_ttyp (), is_nonblocking ()))
> 
> 
> I ended up prepending two CancelIo call just above of 
> acquire_output_mutex located in fhandler_pty_master::close of pty.cc.
> 
>  >  CancelIo(get_ttyp()->to_master());
>  >  CancelIo(get_ttyp()->to_master_nat());
> acquire_output_mutex (mutex_timeout);
> 
> Hope it helps

I cannot reproduce the issue.

1) Which cygwin version do you use?
2) Is this really the same problem with the problem original post reported?
   (i.e. reproducible with 3.6.0-0.139 and not reproduced with 3.5.3)

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Fri, 28 Jun 2024 21:17:26 +0900
Takashi Yano wrote:
> Sorry for very late replay.
> 
> On Mon, 3 Jun 2024 15:20:32 +0200
> Johannes Khoshnazar-Thoma wrote:
> > We did more testing and it looks like the name of the event
> > that signals console master thread start and end is shared between
> > unrelated processes (it uses the console minor which is always (?)
> > 0 when running from a powershell).
> > 
> > So since it is a two-state event (as opposed to a semaphore)
> > in theory the following can happen:
> > 
> > Process A   Process B
> > SetEvent(e)
> > SetEvent(e)
> > Waitforevent(e)
> > Waitforevent(e)
> 
> This should not happen. Master thread is unique to console.
> get_minor() number is always 0 for the first opened console.
> If you open another powershell window and start cygwin process
> while the first cygwin process is still active, the get_minor()
> returns 1.
> 
> Waiting for thread_sync_event is executed only
>   if (shared_console_info[unit] && con.owner == myself->pid)
> con.owner is in the shared memory which is shared among all
> processes started in the same console. Therefore, only the
> one process start to wait the event.
> 
> > The second SetEvent does nothing. As a result the
> > later Waitforevent is stuck (which is what we observe).
> > 
> > So the question is: why should this event be used in
> > unrelated cygwin processes? Is there a technical reason
> > we don't understand (yet) for doing that (sharing the event).
> > 
> > We patched cygwin to use pseudo random event names (the
> > tm_usec field of gettimeofday()) and the stuckness vanished.
> > So unless there is a reason for sharing the event between
> > cygwin processes this patch should work:
> 
> Do you really confirm that your patch resolves the issue?
> If so, the cause might be some kind of race issue.

There was similar bug in cygwin 3.5.1, however, it has been
already fixed in 3.5.3.
https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=fc5e9525453fea7c27b0e13635ae54abaa0db69d

I believe your problem is reproducible with 3.5.3. Right?

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

Sorry for very late replay.

On Mon, 3 Jun 2024 15:20:32 +0200
Johannes Khoshnazar-Thoma wrote:
> We did more testing and it looks like the name of the event
> that signals console master thread start and end is shared between
> unrelated processes (it uses the console minor which is always (?)
> 0 when running from a powershell).
> 
> So since it is a two-state event (as opposed to a semaphore)
> in theory the following can happen:
> 
> Process A Process B
> SetEvent(e)
>   SetEvent(e)
> Waitforevent(e)
>   Waitforevent(e)

This should not happen. Master thread is unique to console.
get_minor() number is always 0 for the first opened console.
If you open another powershell window and start cygwin process
while the first cygwin process is still active, the get_minor()
returns 1.

Waiting for thread_sync_event is executed only
  if (shared_console_info[unit] && con.owner == myself->pid)
con.owner is in the shared memory which is shared among all
processes started in the same console. Therefore, only the
one process start to wait the event.

> The second SetEvent does nothing. As a result the
> later Waitforevent is stuck (which is what we observe).
> 
> So the question is: why should this event be used in
> unrelated cygwin processes? Is there a technical reason
> we don't understand (yet) for doing that (sharing the event).
> 
> We patched cygwin to use pseudo random event names (the
> tm_usec field of gettimeofday()) and the stuckness vanished.
> So unless there is a reason for sharing the event between
> cygwin processes this patch should work:

Do you really confirm that your patch resolves the issue?
If so, the cause might be some kind of race issue.

-- 
Takashi Yano 

-- 
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

Re: Analyze dependencies of a cygwin package

[Takashi Yano via Cygwin]

On Sat, 22 Jun 2024 07:36:19 +0200
Federico Kircheis wrote:
> ffmpeg, as far as I've could see, on Debian does not seem to depend 
> transitively on clang.

ffmpeg on fedora is built with opencl-enabled.
https://src.fedoraproject.org/rpms/ffmpeg/blob/rawhide/f/ffmpeg.spec#_702

I just followed to it. However, cygwin's OpenCL (ocl-icd) suppourts only
pocl as backend which depends on clang. Therefore, on the second thought,
enabling opencl for ffmpeg has more disadvantages than advantages.

I'll release ffmpeg 7.0.1-2 which disables opencl.

> I was already told once that I probably can leave REQUIRES out.
> 
> Currently I'm using it for setting up a minimal test environment where I 
> install only the packages listed in REQUIRES.
> Can cygport give me that information if I do not write any REQUIRES?
> Last time I asked the answer was no, and thus I decided to keep it to 
> ease testing on my side.

Without REQUIRES line, "cygport cmus all" with above patch gives me:

>>> cmus requires: cygwin libao4 libavcodec61 libavformat61 libavutil59 
>>> libcddb2 libcdio18 libcdio_cdda2 libdiscid0 libFLAC12 libiconv2 libmad0 
>>> libmodplug1 libmpcdec7 libncursesw10 libopusfile0 libpulse0 libswresample5 
>>> libvorbisfile3 libwavpack1

I guess this is as you expect (if libav* are free from clang dependency),
isn't it?

-- 
Takashi Yano 

-- 
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

Re: Analyze dependencies of a cygwin package

[Takashi Yano via Cygwin]

On Sat, 22 Jun 2024 07:22:42 +0900
Takashi Yano wrote:
> Hi Federico,
> 
> On Fri, 21 Jun 2024 19:35:32 +0200
> Federico Kircheis wrote:
> > After some investigation, it seems that ffmeg hash clang (which has gcc) 
>   ^^
> > as dependency in its chain.
> > 
> > I would consider it a bug, although not critical.
> 
> Do you mean "ffmpeg has clang as dependency"?
> That's right thing. ffmpeg depends on clang indirectly as follows.
> 
> ffmpeg depends on libavfilter10.
> libavfilter10 depends on libOpenCL1.
> libOpenCL1 depends on libpocl2.
> libpocl2 depends on clang.
> 
> pocl uses Clang as an OpenCL C frontend and LLVM for the kernel
> compiler implementation, and as a portability layer.

BTW, I looked into cmus.cygport of 2.11.0-2 and noticed that you
need to patch for configure to enable ffmpeg plugin as attached. 

With ffmpeg plugin, many of audio formats get supported by cmus.

Furthermore, you do not need to add ffmpeg to "REQUIRES" because
the cmus package itself does not really depend on ffmpeg package
even though it depends libavcodec, libavformat, libavutil and
libswresample.

Maybe, you do not have to add any of packages to "REQUIRES"
because dependencies are added automatically by cygport in most
cases.

-- 
Takashi Yano 
--- origsrc/cmus-2.11.0/configure   2024-05-12 05:04:09.0 +0900
+++ src/cmus-2.11.0/configure   2024-06-22 08:53:45.715725600 +0900
@@ -472,30 +472,14 @@ check_aac()
 check_ffmpeg()
 {
HAVE_FFMPEG_AVCODEC_H=y
-   pkg_config FFMPEG "libavformat libavcodec" || return $?
+   pkg_config FFMPEG "libavformat libavcodec libavutil libswresample" || 
return $?
if check_header "libavcodec/avcodec.h" $FFMPEG_CFLAGS
then
HAVE_FFMPEG_AVCODEC_H=n
else
check_header "ffmpeg/avcodec.h" $FFMPEG_CFLAGS || return $?
fi
-   # ffmpeg api changes so frequently that it is best to compile the module
-   libs="$LDDLFLAGS $FFMPEG_LIBS"
-   cflags="$SOFLAGS $FFMPEG_CFLAGS"
-   if test "$HAVE_FFMPEG_AVCODEC_H" = y
-   then
-   cflags="$cflags -DHAVE_FFMPEG_AVCODEC_H"
-   fi
-   topdir=`dirname "$0"`
-   ffmpeg_code=`cat "$topdir"/ip/ffmpeg.c | sed 's/\\\n//g'`
-   msg_checking "for successful build of ffmpeg.c"
-   if try_compile_link "$ffmpeg_code" $cflags -I$topdir/ip $libs
-   then
-   msg_result yes
-   return 0
-   fi
-   msg_result no
-   return 1
+   return 0
 }
 
 check_string_function()

-- 
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

Re: Analyze dependencies of a cygwin package

[Takashi Yano via Cygwin]

Hi Federico,

On Fri, 21 Jun 2024 19:35:32 +0200
Federico Kircheis wrote:
> After some investigation, it seems that ffmeg hash clang (which has gcc) 
  ^^
> as dependency in its chain.
> 
> I would consider it a bug, although not critical.

Do you mean "ffmpeg has clang as dependency"?
That's right thing. ffmpeg depends on clang indirectly as follows.

ffmpeg depends on libavfilter10.
libavfilter10 depends on libOpenCL1.
libOpenCL1 depends on libpocl2.
libpocl2 depends on clang.

pocl uses Clang as an OpenCL C frontend and LLVM for the kernel
compiler implementation, and as a portability layer.

-- 
Takashi Yano 

-- 
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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

On Sun, 02 Jun 2024 15:14:51 +0200
Bruno Haible wrote:
> Hi Takashi Yano,
> 
> > The result is as follows (submitted as v4 patch).
> > 
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >   /* Sign bit of once_control->state is used as done flag.
> >  Similary, the next significant bit is used as destroyed flag. */
> >   const int done = INT_MIN; /* 0b1000 */
> >   const int destroyed = INT_MIN >> 1;   /* 0b1100 */
> >   if (once_control->state & done)
> > return 0;
> > 
> >   /* The type of &once_control->state is int *, which is compatible with
> >  LONG * (the type of the pointer argument of InterlockedXxx()). */
> >   if ((InterlockedIncrement (&once_control->state) & done) == 0)
> > {
> >   pthread_mutex_lock (&once_control->mutex);
> >   if (!(once_control->state & done))
> > {
> >   init_routine ();
> >   InterlockedOr (&once_control->state, done);
> > }
> >   pthread_mutex_unlock (&once_control->mutex);
> > }
> >   InterlockedDecrement (&once_control->state);
> >   if (InterlockedCompareExchange (&once_control->state,
> >   destroyed, done) == done)
> > pthread_mutex_destroy (&once_control->mutex);
> >   return 0;
> > }
> > ...
> > I believe both codes are equivalent. Could you please check?
> 
> Yes, they are equivalent. This code is free of race conditions. (Let's
> hope I am not making a mistake again.)
> 
> For legibility I would write the constant values as bit masks:
>   0x8000
>   0xc000
> and - following the habit that constant integers should have names in
> upper case - I would rename
>   done → DONE
>   destroyed → DESTROYED

Thanks for checking. I'll push the patch after the modification.

-- 
Takashi Yano 

-- 
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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

On Sat, 1 Jun 2024 12:08:51 -0400
Ken Brown wrote:
> Hi Takashi,
> 
> On 6/1/2024 10:18 AM, Takashi Yano via Cygwin wrote:
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >/* Sign bit of once_control->state is used as done flag.
> >   Similary, the next significant bit is used as destroyed flag. */
> 
>  Typo: Similarly
> 
> >const int done = INT_MIN;/* 0b1000 */
> >const int destroyed = INT_MIN >> 1;  /* 0b1100 */
> 
> Shouldn't the constants in the comments have 32 bits?  Other than that, 
> LGTM.  (But you should wait for Bruno to confirm before you commit.)

Thanks for checking!

-- 
Takashi Yano 

-- 
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

Re: [PATCH v2] Cygwin: pthread: Fix a race issue introduced by the commit 2c5433e5da82

[Takashi Yano via Cygwin]

Hi Bruno,

On Fri, 31 May 2024 16:01:35 +0200
Bruno Haible wrote:
> Hi Takashi Yano,
> 
> > With v3 patch:
> > int
> > pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
> > {
> >   /* Sign bit of once_control->state is used as done flag */
> >   if (once_control->state & INT_MIN)
> > return 0;
> > 
> // HERE: Point A.
> 
> >   /* The type of &once_control->state is int *, which is compatible with
> >  LONG * (the type of the first argument of InterlockedIncrement()). */
> >   InterlockedIncrement (&once_control->state);
> >   pthread_mutex_lock (&once_control->mutex);
> >   if (!(once_control->state & INT_MIN))
> > {
> >   init_routine ();
> >   InterlockedOr (&once_control->state, INT_MIN);
> > }
> >   pthread_mutex_unlock (&once_control->mutex);
> >   if (InterlockedDecrement (&once_control->state) == INT_MIN)
> 
>   // HERE: Point B.
> 
> > pthread_mutex_destroy (&once_control->mutex);
> 
>   // HERE: Point C.
> 
> >   return 0;
> > }
> 
> I said "looks good to me", but unfortunately I have to withdraw this.
> The code to which I pointed you had two race conditions, unfortunately,
> and this code (v3) has the same two race conditions:
> 
> (1) It can happen that the pthread_mutex_destroy is executed twice, which is
> undefined behaviour.
> 
>  thread1  thread2
>  ---  ---
> 
>  Runs upto A. Runs upto A.
> 
>  Runs upto B:
>  sets state to 1,
>  locks,
>  sets state to INT_MIN + 1,
>  unlocks,
>  sets state to INT_MIN.
> 
>   Runs upto B:
>   sets state to INT_MIN + 1,
>   locks,
>   unlocks,
>   sets state to INT_MIN.
> 
>  calls pthread_mutex_destroy
> 
>   calls pthread_mutex_destroy
> 
> (2) It can happen that pthread_mutex_lock is executed on a mutex that is
> already destroyed, which is undefined behaviour.
> 
>  thread1  thread2
>  ---  ---
> 
>  Runs upto A. Runs upto A.
> 
>  Runs upto C:
>  sets state to 1,
>  locks,
>  sets state to INT_MIN + 1,
>  unlocks,
>  sets state to INT_MIN,
>  calls pthread_mutex_destroy
> 
>   Attempts to run upto B:
>   sets state to INT_MIN + 1,
>   locks  -> BOOM, SIGSEGV

I reconsidered how it can be fixed before reading the following your
idea for double-check. The result is as follows (submitted as v4 patch).

int
pthread::once (pthread_once_t *once_control, void (*init_routine) (void))
{
  /* Sign bit of once_control->state is used as done flag.
 Similary, the next significant bit is used as destroyed flag. */
  const int done = INT_MIN; /* 0b1000 */
  const int destroyed = INT_MIN >> 1;   /* 0b1100 */
  if (once_control->state & done)
return 0;

  /* The type of &once_control->state is int *, which is compatible with
 LONG * (the type of the pointer argument of InterlockedXxx()). */
  if ((InterlockedIncrement (&once_control->state) & done) == 0)
{
  pthread_mutex_lock (&once_control->mutex);
  if (!(once_control->state & done))
{
  init_routine ();
  InterlockedOr (&once_control->state, done);
}
  pthread_mutex_unlock (&once_control->mutex);
}
  InterlockedDecrement (&once_control->state);
  if (InterlockedCompareExchange (&once_control->state,
  destroyed, done) == done)
pthread_mutex_destroy (&once_control->mutex);
  return 0;
}

Then, I read your idea below:

> A corrected implementation (that passes 100 runs of the test program)
> is in
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/pthread-once.c;h=4b4a18d2afbb915f8f97ac3ff981f519acaa5996;hb=HEAD#l41
> 
> The fix for race (1) is to extend the "done" part of the state to 2 bits
> instead of just 1 bit, and to use this extra bit to ensure that only one
> of the threads proceeds from B to C.
> 
> The fix for race (2) is to increment num_threads *before* testing the
> 'done' word and, accordingly, to decrement num_threads also when 'done'
> was zero.
> 
> You should be able to transpose the logic accordingly, by using the
> bit mask 0xC000 for the 'done' part and the bit mask 0x3FFF for
> the 'num_threads' part.

I believe both codes are equivalent. 

Re: multithreading broken in Cygwin 3.5.3

[Takashi Yano via Cygwin]

On Wed, 29 May 2024 12:26:31 +0200
Bruno Haible wrote:
> Takashi Yano wrote:
> > As you mentioned in private mail to me, this seems to be a regression of
> > pthread::once() introduced by
> > commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.
> > 
> > I'll submit a patch for that issue shortly.
> 
> My workaround implementation of pthread_once (in gnulib) looks like this:
> 
>   /* This would be the code, for
>typedef struct
>  {
>pthread_mutex_t mutex;
>_Atomic unsigned int num_threads;
>_Atomic unsigned int done;
>  }
>pthread_once_t;
>*/
>   if (once_control->done == 0)
> {
>   once_control->num_threads += 1;
>   pthread_mutex_lock (&once_control->mutex);
>   if (once_control->done == 0)
> {
>   (*initfunction) ();
>   once_control->done = 1;
> }
>   pthread_mutex_unlock (&once_control->mutex);
>   if ((once_control->num_threads -= 1) == 0)
> pthread_mutex_destroy (&once_control->mutex);
> }
> 
> It makes sure that
>   - The last thread that had been dealing with the mutex deletes
> the mutex.
>   - Once the mutex is deleted, is it never again accessed. The
> entry test of the 'done' boolean ensures this.

Thanks for the advice.

The problem is that we cannot change the type of pthread_once_t
for binary compatibility. My patch stops to use
pthread_mutex_t mutex in pthread_once_t however it cannot be
deleted despite it is not used at all.

-- 
Takashi Yano 

-- 
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

Re: multithreading broken in Cygwin 3.5.3

[Takashi Yano via Cygwin]

On Thu, 23 May 2024 20:09:09 +0200
Bruno Haible wrote:
> In Cygwin 3.5.3, on different machines, I see 3 Gnulib tests failing by
> timeout that worked perfectly fine in Cygwin 3.4.6 and older:
>   FAIL: test-call_once2.exe
>   FAIL: test-lock.exe
>   FAIL: test-pthread-once2.exe
> 
> Find here attached a simplified version of test-pthread-once2.c.
> Compile and run:
>   $ x86_64-pc-cygwin-gcc -Wall foo.c
>   $ ./a
> 
> Expected behaviour: Termination within 1 minute.
> Actual behaviour:   Terminates by timeout after 10 minutes.
> 
> When I change
>   #define ENABLE_DEBUGGING 0
> to
>   #define ENABLE_DEBUGGING 1
> the test does lots of output and terminates within 20 seconds.
> Therefore I can't really tell where the problem comes from.
> But I do see some changes in
>   $ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/cygwin/thread.cc
>   $ git diff cygwin-3.4.6 cygwin-3.5.3 winsup/testsuite/winsup.api/pthread

Thanks for the report.

As you mentioned in private mail to me, this seems to be a regression of
pthread::once() introduced by
commit 2c5433e5da8216aaf7458e50c63683c68fb0d3e8.

I'll submit a patch for that issue shortly.

-- 
Takashi Yano 

-- 
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

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

Hi Jeremy,

On Tue, 28 May 2024 10:58:00 +0900
Takashi Yano wrote:
> On Fri, 24 May 2024 19:29:43 -0700 (PDT)
> Jeremy Drake wrote:
> > On Fri, 24 May 2024, Jeremy Drake wrote:
> > 
> > > On Fri, 24 May 2024, Jeremy Drake wrote:
> > >
> > > > Looking at !address, it seems Windows put the PEB, TEBs, and stacks in 
> > > > the
> > > > area where the cygheap should be.  Way to go, ASLR :P
> > >
> > > I think the fix for this would be to add -Wl,--disable-high-entropy-va to
> > > ldh_LDFLAGS, as was done for strace and cygcheck at least.  I used peflags
> > > -d0 /usr/bin/ldh.exe and I'm not seeing a hang after that.
> > 
> > Sorry, that was peflags -e0 not -d0 (dynamicbase is still on):
> > $ peflags -v /usr/bin/ldh.exe
> > /usr/bin/ldh.exe:
> > coff(0x0226[+executable_image,+line_nums_stripped,+bigaddr,+sepdbg])
> > pe(0x0140[+dynamicbase,+nxcompat])
> 
> You are right!
> 
> It seems that VirtualAlloc() in cygheap_init() in mm/cygheap.cc
> fails when the address range which cygwin uses is occupied due to
> high-entropy-va in ldh.exe.
> 
> Thanks for the analysis.

Would you make a patch for that?

-- 
Takashi Yano 

-- 
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

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

On Fri, 24 May 2024 19:29:43 -0700 (PDT)
Jeremy Drake wrote:
> On Fri, 24 May 2024, Jeremy Drake wrote:
> 
> > On Fri, 24 May 2024, Jeremy Drake wrote:
> >
> > > Looking at !address, it seems Windows put the PEB, TEBs, and stacks in the
> > > area where the cygheap should be.  Way to go, ASLR :P
> >
> > I think the fix for this would be to add -Wl,--disable-high-entropy-va to
> > ldh_LDFLAGS, as was done for strace and cygcheck at least.  I used peflags
> > -d0 /usr/bin/ldh.exe and I'm not seeing a hang after that.
> 
> Sorry, that was peflags -e0 not -d0 (dynamicbase is still on):
> $ peflags -v /usr/bin/ldh.exe
> /usr/bin/ldh.exe:
> coff(0x0226[+executable_image,+line_nums_stripped,+bigaddr,+sepdbg])
> pe(0x0140[+dynamicbase,+nxcompat])

You are right!

It seems that VirtualAlloc() in cygheap_init() in mm/cygheap.cc
fails when the address range which cygwin uses is occupied due to
high-entropy-va in ldh.exe.

Thanks for the analysis.

-- 
Takashi Yano 

-- 
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

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

On Fri, 24 May 2024 14:46:40 -0700 (PDT)
Jeremy Drake wrote:
> > Thanks for the report. However, I cannot reproduce the issue.
> > If it always hangs in GetConsoleProcessList (), I doubt it is not a cygwin
> > bug but a windows bug.
> >
> > By any chance, is the number of processes that attach to the same pty more
> > than 32768 in your environment?
> >
> 
> I doubt it, I was running a shell with this command:
> find /usr/bin -name \*.dll -printf '%p:\n' -exec ldd '{}' \;

Thanks for the details. I could reproduce the issue.
It seems that ldh.exe (which is called from ldd?) falls into infinite loop.
However, gdb cannot attach to ldh.exe...

-- 
Takashi Yano 

-- 
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

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

On Sat, 25 May 2024 04:54:24 +0900
Takashi Yano wrote:
> By any chance, is the number of processes that attach to the same pty more
> than 32768 in your environment?

s/32768/8192/

-- 
Takashi Yano 

-- 
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

Re: frequent hangs running ldd

[Takashi Yano via Cygwin]

On Fri, 24 May 2024 11:50:35 -0700 (PDT)
Jeremy Drake wrote:
> 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!GetConsoleScreenBufferInfoEx ()
>from /c/Windows/System32/KERNELBASE.dll
> #2  0x7ffecbef58dc in KERNELBASE!GetConsoleTitleW ()
>from /c/Windows/System32/KERNELBASE.dll
> #3  0x7ffecbfb8195 in KERNELBASE!GetConsoleProcessList ()
>from /c/Windows/System32/KERNELBASE.dll
> #4  0x00018015851f in fhandler_pty_common::get_console_process_id (
> pid=19348, match=match@entry=true, cygwin=cygwin@entry=false,
> stub_only=stub_only@entry=false, nat=nat@entry=false)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/pty.cc:95
> #5  0x000180101e3b in fhandler_console::attach_console (
> owner=, err=err@entry=0x0)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:76
> #6  0x000180102d40 in fhandler_console::set_output_mode (m=tty::native,
> t=0x1a0030028, p=0x800021d68)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:853
> #7  0x00018010d6cc in fhandler_console::set_console_mode_to_native ()
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:4189
> #8  0x00018010d71d in ContinueDebugEvent_Hooked (p=26628, t=26656, 
> s=65538)
> at 
> /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler/console.cc:4238
> #9  0x000100401bd7 in ?? ()
> #10 0x00010040279f in ?? ()
> #11 0x0001800483a7 in dll_crt0_1 ()
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/dcrt0.cc:1015
> #12 0x000180045f63 in _cygtls::call2 (this=0x7ce00,
> func=0x180047240 , arg=0x0,
> buf=buf@entry=0x7cdf0)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:41
> #13 0x000180046014 in _cygtls::call (func=,
> arg=)
> at /C/_/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc:28
> #14 0x in ?? ()
> 
> Other attempts without symbols showed the same Windows APIs at least.

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 in your environment?

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Wed, 15 May 2024 17:48:49 +0200
Johannes Khoshnazar-Thoma wrote:
> Hi again,
> 
> Am 15.05.24 um 17:37 schrieb Johannes Khoshnazar-Thoma:
> > Hi again,
> >
> > Am 23.04.24 um 12:26 schrieb Takashi Yano:
>  Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
>  wihch is the latest cygwin release?
> 
> >
> > We retried the tests with cygwin1.dll 3.5.3-1 and it looks like
> > the issue is still there. Here's an excerpt from the gdb debug
> > session:
> >
> Sorry somehow the formatting got messed up I try again:

Thanks for testing and the additional information.

> (gdb) info thread
>Id   Target Id Frame
> * 1Thread 0x11cc 0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () 
> from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>2Thread 0x8ec  0x7ffe579d5ee4 in ntdll!ZwReadFile () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>3Thread 0x55c  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject 
> () from C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>4Thread 0x131c 0x7ffe579d95f4 in 
> ntdll!ZwWaitForWorkViaWorkerFactory () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
>5Thread 0x9b8  0x7ffe579d95f4 in 
> ntdll!ZwWaitForWorkViaWorkerFactory () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x11cc)]
> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) bt
> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> #1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
> C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
> #2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914

Line 1914 of fhandler/console.cc is:
  WaitForSingleObject (thread_sync_event, INFINITE);

This waits termination of cons_master_thread(). However, it does not seem
that the cons_master_thread exists in thread list obove. If the thread was
terminated normally, thread_sync_event should has been set.

> #0  0x7ffe579d5ea4 in ntdll!ZwWaitForSingleObject () from 
> C:\src\dlls-syms\ntdll.dll\6502806A1cf000\ntdll.dll
> (gdb) up
> #1  0x7ffe54156d1f in WaitForSingleObjectEx () from 
> C:\src\dlls-syms\KERNELBASE.dll\660F5EEC21e000\KERNELBASE.dll
> (gdb)
> #2  0x7ffe4a2033a0 in fhandler_console::close (this=0x89030) at 
> /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc:1914
> 1914in /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/fhandler/console.cc
> (gdb) p thread_sync_event
> $6 = (HANDLE) 0x1510
> (gdb) p name
> $7 = "cygcons.thread_sync.0", '\000' , "r", '\000'  183 times>...
> (gdb) p con.owner
> No symbol "con" in current context.
> (gdb) p master_thread_started
> $8 = true
> (gdb) p unit
> $9 = 0
> (gdb) p shared_console_info
> $10 = {0x1a003, 0x0 }
> (gdb)

fhandler_console::close() was called twice? Or master thread had crashed
without setting thread_sync_event?

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Tue, 23 Apr 2024 11:20:16 +0200
Johannes Khoshnazar-Thoma wrote:
> Am 22.04.24 um 20:51 schrieb Takashi Yano:
> > On Mon, 22 Apr 2024 14:50:51 +0200
> > Johannes Khoshnazar-Thoma wrote:
> >> Hi cygwin team :)
> >>
> >> I have found something what may be a cygwin bug. Sometimes
> >> (1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
> >> user mode programs originally written for Linux) hangs for several
> >> days on exiting (closing the console). I got a minidump and analyzed
> >> the dump with gdb (the minidump enabled version at 
> >> https://github.com/ssbssa/gdb)
> >>
> >> I have to note that the application (drbdadm.exe) is run from a
> >> Windows Service. Furthermore it is not a full cygwin installation
> >> however the cygwin1.dll (3.4.10-1) is in the $PATH.
> >
> > Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
> > wihch is the latest cygwin release?
> >
> Thanks for your reply.
> 
> Yes, sure, will test it with 3.5.3 as well. Due to round trip times
> with the client this may take one or 2 weeks, however.

Thanks in advance.

> Just wanted to ask if the 3.4 branch is end of life?

3.4 branch: no more bug fix nor release.
3.5 branch: bug fix releases only.
3.6 branch: will be released with new features.

-- 
Takashi Yano 

-- 
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

Re: cygwin application hangs on closing console

[Takashi Yano via Cygwin]

On Mon, 22 Apr 2024 14:50:51 +0200
Johannes Khoshnazar-Thoma wrote:
> Hi cygwin team :)
> 
> I have found something what may be a cygwin bug. Sometimes
> (1 out of 1000 times) a drbdadm.exe process (which is part of WinDRBD's
> user mode programs originally written for Linux) hangs for several
> days on exiting (closing the console). I got a minidump and analyzed
> the dump with gdb (the minidump enabled version at 
> https://github.com/ssbssa/gdb)
> 
> I have to note that the application (drbdadm.exe) is run from a
> Windows Service. Furthermore it is not a full cygwin installation
> however the cygwin1.dll (3.4.10-1) is in the $PATH.

Thanks for the report. Could you please test cygwin1.dll 3.5.3-1
wihch is the latest cygwin release?

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Mon, 18 Mar 2024 12:09:06 +0900
Takashi Yano wrote:
> On Sun, 17 Mar 2024 14:10:55 +0100
> Dimitry Andric wrote:
> > On 17 Mar 2024, at 13:50, Dimitry Andric  
> > wrote:
> > > 
> > > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin  
> > > wrote:
> > > ...
> > >> 
> > >> I also test your test case:
> > >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait 
> > >> -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done
> > >> in Linux (Debian 12.5), and the issue reproduced!
> > > 
> > > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors 
> > > out with 127 after ~50-200 loops.
> > 
> > Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently 
> > gives 127 in this area:
> > 
> > https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227
> > 
> >211  #if defined (JOB_CONTROL)
> >212if (nflag)
> >213  {
> >214if (list)
> >215  {
> >216opt = set_waitlist (list);
> >217if (opt == 0)
> >218  WAIT_RETURN (127);
> >219wflags |= JWAIT_WAITING;
> >220  }
> >221
> >222status = wait_for_any_job (wflags, &pstat);
> >223if (vname && status >= 0)
> >224  builtin_bind_var_to_int (vname, pstat.pid, bindflags);
> >225
> >226if (status < 0)
> > => 227  status = 127;
> >228if (list)
> >229  unset_waitlist ();
> >230WAIT_RETURN (status);
> >231  }
> >232  #endif
> > 
> > So for some reason, wait_for_any_job() returns a negative value in this 
> > particular situation.
> 
> Line 218 looks also suspicious.

Probably, this is not a bug. man bash says:
  If  the  -n option is supplied, wait waits for a single job from
  the list of ids or, if no ids are supplied, any job, to complete
  and returns its exit status.  If none of the supplied  arguments
  is a child of the shell, or if no arguments are supplied and the
  shell  has no unwaited‐for children, the exit status is 127.

If the background process exited before calling 'wait -n', it returns 127.
This is very different from wait() system call, which is necessary for
any background joubs, otherwise zombie remains.

In the shell, it is not necessary to call wait command for background jobs,
therefore exit status of the background job which already exited is not held
anymore.

So, actual bug is in the test case.

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 14:10:55 +0100
Dimitry Andric wrote:
> On 17 Mar 2024, at 13:50, Dimitry Andric  
> wrote:
> > 
> > On 17 Mar 2024, at 13:35, Takashi Yano via Cygwin  wrote:
> > ...
> >> 
> >> I also test your test case:
> >> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait -n 
> >> || { echo 2: $?; exit 1; }'; do echo $((i++)); done
> >> in Linux (Debian 12.5), and the issue reproduced!
> > 
> > Yeah, same here with bash 5.1.16(1)-release on Ubuntu 22.04. It errors out 
> > with 127 after ~50-200 loops.
> 
> Having built bash master (bash-5.2-27-gf3b6bd19) here, it consistently gives 
> 127 in this area:
> 
> https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/wait.def#n227
> 
>211  #if defined (JOB_CONTROL)
>212if (nflag)
>213  {
>214if (list)
>215  {
>216opt = set_waitlist (list);
>217if (opt == 0)
>218  WAIT_RETURN (127);
>219wflags |= JWAIT_WAITING;
>220  }
>221
>222status = wait_for_any_job (wflags, &pstat);
>223if (vname && status >= 0)
>224  builtin_bind_var_to_int (vname, pstat.pid, bindflags);
>225
>226if (status < 0)
> => 227  status = 127;
>228if (list)
>229  unset_waitlist ();
>230WAIT_RETURN (status);
>231  }
>232  #endif
> 
> So for some reason, wait_for_any_job() returns a negative value in this 
> particular situation.

Line 218 looks also suspicious.

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 21:15:17 +0900
Takashi Yano wrote:
> On Sun, 17 Mar 2024 21:03:58 +0900
> Takashi Yano wrote:
> > On Sun, 17 Mar 2024 19:21:16 +0900
> > Takashi Yano wrote:
> > > On Sun, 17 Mar 2024 13:03:40 +0300
> > > Alexey Izbyshev wrote:
> > > > On 2024-03-17 12:27, Takashi Yano wrote:
> > > > > On Sun, 17 Mar 2024 12:01:55 +0300
> > > > > Alexey Izbyshev wrote:
> > > > >> On 2024-03-17 11:44, Takashi Yano wrote:
> > > > >> > On Sun, 17 Mar 2024 11:14:16 +0300
> > > > >> > Alexey Izbyshev wrote:
> > > > >> >> Hello,
> > > > >> >>
> > > > >> >> I've been getting occasional "Error 127" from make -jN on 
> > > > >> >> seemingly
> > > > >> >> random jobs. After reducing the set of jobs and eventually 
> > > > >> >> eliminating
> > > > >> >> make, I've arrived to this one-liner:
> > > > >> >>
> > > > >> >> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 
> > > > >> >> 2: $?'
> > > > >> >>
> > > > >> >> When run repeatedly, the second "wait -n" often reports 127.
> > > > >> >>
> > > > >> >> I've reproduced this in the following environments:
> > > > >> >>
> > > > >> >> * Cygwin 3.5.1, Windows 10 22H2 x64
> > > > >> >> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> > > > >> >>
> > > > >> >> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.
> > > > >> >
> > > > >> > Could you please try latest cygwin 3.6.0 (TEST) ?
> > > > >> 
> > > > >> Tested with 3.6.0-0.82.gfc691d0246b9 on Windows 10 22H2 x64, the 
> > > > >> problem
> > > > >> still occurs.
> > > > > 
> > > > > In my evrironmen, trial for 1 hour does not reproduce the issue.
> > > > > Could you please let us know your environment, i.e. CPU, amount of
> > > > > memory, and so on?
> > > > 
> > > > It's been reproduced in a variety of environments:
> > > > 
> > > > * Windows 10 22H2 x64, Intel Core i7 11700, 32 GB RAM
> > > > * Windows 10 22H2 x64, Intel Core i7 9700, 32 GB RAM
> > > > * Windows 10 22H2 x64, Intel Core i7 6700, 32 GB RAM
> > > > * Windows 7 SP1 x64, Intel Core i7 6700, 32 GB RAM
> > > > 
> > > > I'm surprised that you're not hitting it very quickly. The following 
> > > > loop usually fails after a few iterations (rarely a hundred or so) in 
> > > > my 
> > > > tests:
> > > > 
> > > > while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait 
> > > > -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done
> > > 
> > > Thanks. My main PC still runs the above test for more than 15000 counts.
> > > So, I tried another PC which CPU is Core i5 540M and could reproduce
> > > the issue about 1 time per a few hundreds count.
> > > 
> > > I also tried to run sleep 0.1 instead of true, then, the issue happens
> > > 1 time per a few decades counts.
> > > 
> > > I'll look into this problem. Thanks for the report.
> > 
> > In my environment, the issue is reproducible even with cygwin 3.3.6
> > (32bit, i.e. WOW64) and bash 4.4.12(3)-release (i686-pc-cygwin).
> > 
> > What are the versions of bash in each systems?
> 
> And, the attached simple test case in C which does very similar things
> with bash command could not reproduce the problem.
> 
> Can you reproduce the issue with attached STC?

I also test your test case:
while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait -n || { 
echo 2: $?; exit 1; }'; do echo $((i++)); done
in Linux (Debian 12.5), and the issue reproduced!

It seems that this is a bug of upstream of bash.

Eric, Corinna, any idea?

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 21:03:58 +0900
Takashi Yano wrote:
> On Sun, 17 Mar 2024 19:21:16 +0900
> Takashi Yano wrote:
> > On Sun, 17 Mar 2024 13:03:40 +0300
> > Alexey Izbyshev wrote:
> > > On 2024-03-17 12:27, Takashi Yano wrote:
> > > > On Sun, 17 Mar 2024 12:01:55 +0300
> > > > Alexey Izbyshev wrote:
> > > >> On 2024-03-17 11:44, Takashi Yano wrote:
> > > >> > On Sun, 17 Mar 2024 11:14:16 +0300
> > > >> > Alexey Izbyshev wrote:
> > > >> >> Hello,
> > > >> >>
> > > >> >> I've been getting occasional "Error 127" from make -jN on seemingly
> > > >> >> random jobs. After reducing the set of jobs and eventually 
> > > >> >> eliminating
> > > >> >> make, I've arrived to this one-liner:
> > > >> >>
> > > >> >> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 2: 
> > > >> >> $?'
> > > >> >>
> > > >> >> When run repeatedly, the second "wait -n" often reports 127.
> > > >> >>
> > > >> >> I've reproduced this in the following environments:
> > > >> >>
> > > >> >> * Cygwin 3.5.1, Windows 10 22H2 x64
> > > >> >> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> > > >> >>
> > > >> >> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.
> > > >> >
> > > >> > Could you please try latest cygwin 3.6.0 (TEST) ?
> > > >> 
> > > >> Tested with 3.6.0-0.82.gfc691d0246b9 on Windows 10 22H2 x64, the 
> > > >> problem
> > > >> still occurs.
> > > > 
> > > > In my evrironmen, trial for 1 hour does not reproduce the issue.
> > > > Could you please let us know your environment, i.e. CPU, amount of
> > > > memory, and so on?
> > > 
> > > It's been reproduced in a variety of environments:
> > > 
> > > * Windows 10 22H2 x64, Intel Core i7 11700, 32 GB RAM
> > > * Windows 10 22H2 x64, Intel Core i7 9700, 32 GB RAM
> > > * Windows 10 22H2 x64, Intel Core i7 6700, 32 GB RAM
> > > * Windows 7 SP1 x64, Intel Core i7 6700, 32 GB RAM
> > > 
> > > I'm surprised that you're not hitting it very quickly. The following 
> > > loop usually fails after a few iterations (rarely a hundred or so) in my 
> > > tests:
> > > 
> > > while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait 
> > > -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done
> > 
> > Thanks. My main PC still runs the above test for more than 15000 counts.
> > So, I tried another PC which CPU is Core i5 540M and could reproduce
> > the issue about 1 time per a few hundreds count.
> > 
> > I also tried to run sleep 0.1 instead of true, then, the issue happens
> > 1 time per a few decades counts.
> > 
> > I'll look into this problem. Thanks for the report.
> 
> In my environment, the issue is reproducible even with cygwin 3.3.6
> (32bit, i.e. WOW64) and bash 4.4.12(3)-release (i686-pc-cygwin).
> 
> What are the versions of bash in each systems?

And, the attached simple test case in C which does very similar things
with bash command could not reproduce the problem.

Can you reproduce the issue with attached STC?

-- 
Takashi Yano 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
	int status;
	int num = 2;
	int cnt = 0;
	if (argc > 1) num = atoi(argv[1]);
	while (1) {
		for (int i=0; i
-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 19:21:16 +0900
Takashi Yano wrote:
> On Sun, 17 Mar 2024 13:03:40 +0300
> Alexey Izbyshev wrote:
> > On 2024-03-17 12:27, Takashi Yano wrote:
> > > On Sun, 17 Mar 2024 12:01:55 +0300
> > > Alexey Izbyshev wrote:
> > >> On 2024-03-17 11:44, Takashi Yano wrote:
> > >> > On Sun, 17 Mar 2024 11:14:16 +0300
> > >> > Alexey Izbyshev wrote:
> > >> >> Hello,
> > >> >>
> > >> >> I've been getting occasional "Error 127" from make -jN on seemingly
> > >> >> random jobs. After reducing the set of jobs and eventually eliminating
> > >> >> make, I've arrived to this one-liner:
> > >> >>
> > >> >> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 2: $?'
> > >> >>
> > >> >> When run repeatedly, the second "wait -n" often reports 127.
> > >> >>
> > >> >> I've reproduced this in the following environments:
> > >> >>
> > >> >> * Cygwin 3.5.1, Windows 10 22H2 x64
> > >> >> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> > >> >>
> > >> >> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.
> > >> >
> > >> > Could you please try latest cygwin 3.6.0 (TEST) ?
> > >> 
> > >> Tested with 3.6.0-0.82.gfc691d0246b9 on Windows 10 22H2 x64, the 
> > >> problem
> > >> still occurs.
> > > 
> > > In my evrironmen, trial for 1 hour does not reproduce the issue.
> > > Could you please let us know your environment, i.e. CPU, amount of
> > > memory, and so on?
> > 
> > It's been reproduced in a variety of environments:
> > 
> > * Windows 10 22H2 x64, Intel Core i7 11700, 32 GB RAM
> > * Windows 10 22H2 x64, Intel Core i7 9700, 32 GB RAM
> > * Windows 10 22H2 x64, Intel Core i7 6700, 32 GB RAM
> > * Windows 7 SP1 x64, Intel Core i7 6700, 32 GB RAM
> > 
> > I'm surprised that you're not hitting it very quickly. The following 
> > loop usually fails after a few iterations (rarely a hundred or so) in my 
> > tests:
> > 
> > while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait 
> > -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done
> 
> Thanks. My main PC still runs the above test for more than 15000 counts.
> So, I tried another PC which CPU is Core i5 540M and could reproduce
> the issue about 1 time per a few hundreds count.
> 
> I also tried to run sleep 0.1 instead of true, then, the issue happens
> 1 time per a few decades counts.
> 
> I'll look into this problem. Thanks for the report.

In my environment, the issue is reproducible even with cygwin 3.3.6
(32bit, i.e. WOW64) and bash 4.4.12(3)-release (i686-pc-cygwin).

What are the versions of bash in each systems?

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 13:03:40 +0300
Alexey Izbyshev wrote:
> On 2024-03-17 12:27, Takashi Yano wrote:
> > On Sun, 17 Mar 2024 12:01:55 +0300
> > Alexey Izbyshev wrote:
> >> On 2024-03-17 11:44, Takashi Yano wrote:
> >> > On Sun, 17 Mar 2024 11:14:16 +0300
> >> > Alexey Izbyshev wrote:
> >> >> Hello,
> >> >>
> >> >> I've been getting occasional "Error 127" from make -jN on seemingly
> >> >> random jobs. After reducing the set of jobs and eventually eliminating
> >> >> make, I've arrived to this one-liner:
> >> >>
> >> >> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 2: $?'
> >> >>
> >> >> When run repeatedly, the second "wait -n" often reports 127.
> >> >>
> >> >> I've reproduced this in the following environments:
> >> >>
> >> >> * Cygwin 3.5.1, Windows 10 22H2 x64
> >> >> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> >> >>
> >> >> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.
> >> >
> >> > Could you please try latest cygwin 3.6.0 (TEST) ?
> >> 
> >> Tested with 3.6.0-0.82.gfc691d0246b9 on Windows 10 22H2 x64, the 
> >> problem
> >> still occurs.
> > 
> > In my evrironmen, trial for 1 hour does not reproduce the issue.
> > Could you please let us know your environment, i.e. CPU, amount of
> > memory, and so on?
> 
> It's been reproduced in a variety of environments:
> 
> * Windows 10 22H2 x64, Intel Core i7 11700, 32 GB RAM
> * Windows 10 22H2 x64, Intel Core i7 9700, 32 GB RAM
> * Windows 10 22H2 x64, Intel Core i7 6700, 32 GB RAM
> * Windows 7 SP1 x64, Intel Core i7 6700, 32 GB RAM
> 
> I'm surprised that you're not hitting it very quickly. The following 
> loop usually fails after a few iterations (rarely a hundred or so) in my 
> tests:
> 
> while bash -c 'true & true & wait -n || { echo 1: $?; exit 1; } && wait 
> -n || { echo 2: $?; exit 1; }'; do echo $((i++)); done

Thanks. My main PC still runs the above test for more than 15000 counts.
So, I tried another PC which CPU is Core i5 540M and could reproduce
the issue about 1 time per a few hundreds count.

I also tried to run sleep 0.1 instead of true, then, the issue happens
1 time per a few decades counts.

I'll look into this problem. Thanks for the report.

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 12:01:55 +0300
Alexey Izbyshev wrote:
> On 2024-03-17 11:44, Takashi Yano wrote:
> > On Sun, 17 Mar 2024 11:14:16 +0300
> > Alexey Izbyshev wrote:
> >> Hello,
> >> 
> >> I've been getting occasional "Error 127" from make -jN on seemingly
> >> random jobs. After reducing the set of jobs and eventually eliminating
> >> make, I've arrived to this one-liner:
> >> 
> >> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 2: $?'
> >> 
> >> When run repeatedly, the second "wait -n" often reports 127.
> >> 
> >> I've reproduced this in the following environments:
> >> 
> >> * Cygwin 3.5.1, Windows 10 22H2 x64
> >> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> >> 
> >> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.
> > 
> > Could you please try latest cygwin 3.6.0 (TEST) ?
> 
> Tested with 3.6.0-0.82.gfc691d0246b9 on Windows 10 22H2 x64, the problem 
> still occurs.

In my evrironmen, trial for 1 hour does not reproduce the issue.
Could you please let us know your environment, i.e. CPU, amount of 
memory, and so on?

-- 
Takashi Yano 

-- 
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

Re: Bogus exit code 127 from a child process

[Takashi Yano via Cygwin]

On Sun, 17 Mar 2024 11:14:16 +0300
Alexey Izbyshev wrote:
> Hello,
> 
> I've been getting occasional "Error 127" from make -jN on seemingly 
> random jobs. After reducing the set of jobs and eventually eliminating 
> make, I've arrived to this one-liner:
> 
> bash -c 'true & true & wait -n || echo 1: $? && wait -n || echo 2: $?'
> 
> When run repeatedly, the second "wait -n" often reports 127.
> 
> I've reproduced this in the following environments:
> 
> * Cygwin 3.5.1, Windows 10 22H2 x64
> * Cygwin 3.4.6, Windows 10 22H2 x64 and Windows 7 x64
> 
> I couldn't reproduce it in Cygwin 3.3.6 (WOW64) on Windows 7 x64.

Could you please try latest cygwin 3.6.0 (TEST) ?

-- 
Takashi Yano 

-- 
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

Re: Non-Cygwin programs touching a pipe's read side makes the write side unselectable

[Takashi Yano via Cygwin]

On Sun, 10 Mar 2024 17:38:53 +0900
Takashi Yano wrote:
> On Sun, 10 Mar 2024 05:49:43 +
> wh wrote:
> > Here's how to reproduce this behavior.
> > 
> > In test3.pl:
> > 
> > #!/usr/bin/perl
> > my $wfds = '';
> > vec($wfds, fileno(STDOUT), 1) = 1;
> > sleep 1;
> > print STDERR "selecting\n";
> > select undef, $wfds, undef, undef;
> > print STDERR "ready\n";
> > print "abc\n";
> > 
> > Then run:
> > 
> > # curl is as shipped with Windows, /cygdrive/c/Windows/system32/curl
> > ./test3.pl | (curl --version && cat)
> > 
> > Expected result:
> > 
> > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
> > ...
> > selecting
> > ready
> > abc
> > 
> > Actual result:
> > 
> > curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
> > ...
> > selecting
> > (hang)
> > 
> > Using strace on perl, it ends with
> > 
> >95  332358 [main] perl 733 clock_nanosleep: clock_nanosleep (1.0)
> > 1004437 1336795 [main] perl 733 clock_nanosleep: 0 = clock_nanosleep(1, 0, 
> > 1.0, 0.d)
> >   247 1337042 [main] perl 733 time: 1710048216 = time(0x7CA00)
> >  1010 1338052 [main] perl 733 fhandler_console::write: 0xA00051B10, 10
> >   822 1338874 [main] perl 733 fhandler_console::write: 10 = 
> > fhandler_console::write(...)
> >   203 1339077 [main] perl 733 write: 10 = write(2, 0xA00051B10, 10)
> >   254 1339331 [main] perl 733 pselect: pselect (8, 0x0, 0xA000330E0, 0x0, 
> > 0x0, 0x0)
> >   207 1339538 [main] perl 733 pselect: to NULL, us -1
> >   490 1340028 [main] perl 733 dtable::select_write:  fd 1
> >   191 1340219 [main] perl 733 select: sel.always_ready 0
> > --- Process 6888 (pid: 733) thread 784 created
> >   859 1341078 [pipesel] perl 733 cygthread::stub: thread 'pipesel', id 
> > 0x310, stack_ptr 0x2BBCCB0
> >   192 1341270 [main] perl 733 select_stuff::wait: m 3, us 
> > 18446744073709551615, wmfo_timeout -1
> >   196 1341466 [pipesel] perl 733 SetThreadName: SetThreadDescription() 
> > failed.  1000
> > 
> > Pipesel never comes back.
> > 
> > Other info:
> > 
> > - Replacing cat with tee (tee with no args is the same as cat) makes it 
> > work. tee reads in smaller chunks, while cat reads at the pipe buffer size. 
> > Comments in select.cc suggest this is important, but I don't understand it 
> > all.
> > - Removing the curl makes it work
> > - Using curl  > - Using a Cygwin program instead of a non-Cygwin program e.g. id instead of 
> > curl makes it work
> > - Removing the select confirms that nothing weird is breaking the pipe, and 
> > the "abc' shows up properly
> > 
> > There was a report in MSYS2 
> > https://github.com/msys2/msys2-runtime/issues/202 also about pipes to 
> > external programs, but there are some differences. In this scenario the 
> > non-Cygwin curl doesn't actually read anything from the pipe, and it should 
> > have exited before the select call. I tried a build of MSYS2 with their 
> > fix, and it still hangs in this way.
> 
> Thanks for the report. I looked into this problem, and found the cause.
> Let me consider how to fix that.

I have submitted the patch for this issue. Now it is waiting for the review.

Thanks.

-- 
Takashi Yano 

-- 
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

Re: Non-Cygwin programs touching a pipe's read side makes the write side unselectable

[Takashi Yano via Cygwin]

On Sun, 10 Mar 2024 05:49:43 +
wh wrote:
> Here's how to reproduce this behavior.
> 
> In test3.pl:
> 
> #!/usr/bin/perl
> my $wfds = '';
> vec($wfds, fileno(STDOUT), 1) = 1;
> sleep 1;
> print STDERR "selecting\n";
> select undef, $wfds, undef, undef;
> print STDERR "ready\n";
> print "abc\n";
> 
> Then run:
> 
> # curl is as shipped with Windows, /cygdrive/c/Windows/system32/curl
> ./test3.pl | (curl --version && cat)
> 
> Expected result:
> 
> curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
> ...
> selecting
> ready
> abc
> 
> Actual result:
> 
> curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
> ...
> selecting
> (hang)
> 
> Using strace on perl, it ends with
> 
>95  332358 [main] perl 733 clock_nanosleep: clock_nanosleep (1.0)
> 1004437 1336795 [main] perl 733 clock_nanosleep: 0 = clock_nanosleep(1, 0, 
> 1.0, 0.d)
>   247 1337042 [main] perl 733 time: 1710048216 = time(0x7CA00)
>  1010 1338052 [main] perl 733 fhandler_console::write: 0xA00051B10, 10
>   822 1338874 [main] perl 733 fhandler_console::write: 10 = 
> fhandler_console::write(...)
>   203 1339077 [main] perl 733 write: 10 = write(2, 0xA00051B10, 10)
>   254 1339331 [main] perl 733 pselect: pselect (8, 0x0, 0xA000330E0, 0x0, 
> 0x0, 0x0)
>   207 1339538 [main] perl 733 pselect: to NULL, us -1
>   490 1340028 [main] perl 733 dtable::select_write:  fd 1
>   191 1340219 [main] perl 733 select: sel.always_ready 0
> --- Process 6888 (pid: 733) thread 784 created
>   859 1341078 [pipesel] perl 733 cygthread::stub: thread 'pipesel', id 0x310, 
> stack_ptr 0x2BBCCB0
>   192 1341270 [main] perl 733 select_stuff::wait: m 3, us 
> 18446744073709551615, wmfo_timeout -1
>   196 1341466 [pipesel] perl 733 SetThreadName: SetThreadDescription() 
> failed.  1000
> 
> Pipesel never comes back.
> 
> Other info:
> 
> - Replacing cat with tee (tee with no args is the same as cat) makes it work. 
> tee reads in smaller chunks, while cat reads at the pipe buffer size. 
> Comments in select.cc suggest this is important, but I don't understand it 
> all.
> - Removing the curl makes it work
> - Using curl  - Using a Cygwin program instead of a non-Cygwin program e.g. id instead of 
> curl makes it work
> - Removing the select confirms that nothing weird is breaking the pipe, and 
> the "abc' shows up properly
> 
> There was a report in MSYS2 https://github.com/msys2/msys2-runtime/issues/202 
> also about pipes to external programs, but there are some differences. In 
> this scenario the non-Cygwin curl doesn't actually read anything from the 
> pipe, and it should have exited before the select call. I tried a build of 
> MSYS2 with their fix, and it still hangs in this way.

Thanks for the report. I looked into this problem, and found the cause.
Let me consider how to fix that.

-- 
Takashi Yano 

-- 
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

Re: libfontconfig-common-2.15.0-2 system font cache directory settings seem to be wrong

[Takashi Yano via Cygwin]

On Fri, 08 Mar 2024 21:53:10 +0900 (JST)
Masamichi Hosoda wrote:
> Hi
> 
> If I understand correctly,
> the system font cache directory setting in /etc/fonts/fonts.conf
> provided by libfontconfig-common-2.15.0-2 is wrong.
> 
> In /etc/fonts/fonts.conf provided by libfontconfig-common-2.13.1-2
> 
> ```
>/var/cache/fontconfig
> ```
> 
> So `fc-cache -s` creates system font cache files in `/var/cache/fontconfig`.
> It is correct because `/var/cache` is a common system cache directory.
> 
> In /etc/fonts/fonts.conf provided by libfontconfig-common-2.15.0-2
> 
> ```
>LOCAL_APPDATA_FONTCONFIG_CACHE
> ```
> 
> So `fc-cache -s` creates system font cache files
> in `./LOCAL_APPDATA_FONTCONFIG_CACHE`.
> `LOCAL_APPDATA_FONTCONFIG_CACHE` directory is created
> in the *current* directory when fc-cache.
> It is wrong because it means that
> processes with different current directories have
> different system font cache directories,
> and the caches are no longer shared.

Thanks for the report. You are right.
I'll release 2.15.0-3 to fix that.

-- 
Takashi Yano 

-- 
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

Re: libfontconfig-devel-2.15.0-1 links wrong DLL

[Takashi Yano via Cygwin]

On Tue, 05 Mar 2024 20:48:38 +0900 (JST)
Masamichi Hosoda wrote:
> libfontconfig-devel-2.15.0-1 links wrong DLL (i.e. libfontconfig-1.dll)

Thanks for the report. I'll fix that and release version 2.15.0-2.

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Mon, 4 Mar 2024 20:00:13 +0900
Takashi Yano via Cygwin wrote:
> On Sun, 3 Mar 2024 13:07:11 +0900
> Takashi Yano wrote:
> > On Sat, 2 Mar 2024 11:49:36 +
> > Kate Deplaix wrote:
> > > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
> > > RAM and with an up-to-date Windows 10.
> > 
> > Thanks for the information. I could reproduce the problem with
> > Core i5 M 540 + 8GB RAM machine.
> > 
> > Let consider how to debug.
> 
> I found the cause. I'll push the patch shortly.
> Thanks!

Please try:
cygwin 3.6.0-0.71.gb160b690b6ac (TEST)

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Sun, 3 Mar 2024 13:07:11 +0900
Takashi Yano wrote:
> On Sat, 2 Mar 2024 11:49:36 +
> Kate Deplaix wrote:
> > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of 
> > RAM and with an up-to-date Windows 10.
> 
> Thanks for the information. I could reproduce the problem with
> Core i5 M 540 + 8GB RAM machine.
> 
> Let consider how to debug.

I found the cause. I'll push the patch shortly.
Thanks!

-- 
Takashi Yano 

-- 
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

Re: openjpeg 2.5.0-1

[Takashi Yano via Cygwin]

Sorry, openjpeg 2.x.x is released in openjpeg2 package.
So, I'll release openjpeg 1.5.2 package later.

On Sun, 03 Mar 2024 15:25:14 +0900
Takashi Yano wrote:
> The following packages have been uploaded to the Cygwin distribution:
> 
> * openjpeg-2.5.0-1
> * libopenjp2_7-2.5.0-1
> * libopenjpeg-devel-2.5.0-1
> 
> The OpenJPEG library is an open-source JPEG 2000 codec written
> in C language. It has been developed in order to promote the use of JPEG 2000,
> the new still-image compression standard from the Joint Photographic Experts
> Group (JPEG).
> -- 
>   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
> 
> The easiest way to unsubscribe is to visit 
> , and click 'Unsubscribe'.
> 
> If you need more information on unsubscribing, start reading here: 
> .

Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Sat, 2 Mar 2024 11:49:36 +
Kate Deplaix wrote:
> I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of RAM 
> and with an up-to-date Windows 10.

Thanks for the information. I could reproduce the problem with
Core i5 M 540 + 8GB RAM machine.

Let consider how to debug.

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Fri, 1 Mar 2024 17:48:52 +
Kate Deplaix wrote:
> Hi,
> 
> Using cygwin 3.6.0-0.66.gc77a5689f7bd I was indeed unable to reproduce the 
> issue.

Thanks for tesing.

> However I'm getting a related but slightly different issue now, where a 
> subprocess randomly (but quite reliably over the whole compilation process) 
> fails with make -j (works fine with -j1 once again)
> 
> Luckily i was able to make a really small test-case this time:
> Using MinGW 11.4.0 with the following test.c file:
> 
> #define UNICODE
> #define _UNICODE
> 
> #include 
> #include 
> 
> int main() {
>   int ret = _wsystem(L"x86_64-w64-mingw32-gcc -dumpversion");
>   if(ret != 0) printf("FOUND %d\n", ret);
> }
> 
> compile using: x86_64_w64-mingw32-gcc ./test.c
> and run using: for i in $(seq 1 100) ; do ./a & done

Thanks for the test case. I tried this test case, however,
I cannot reproduce the second problem, i.e. all 100 processes
exited normally.

To increase system load, I also tried:

#define UNICODE
#define _UNICODE

#include 
#include 

int main(int argc, char *argv[]) {
  wchar_t buf[1024];
  swprintf(buf, 1024, L"x86_64-w64-mingw32-gcc test.c -o %s", argv[1]);
  int ret = _wsystem(buf);
  if(ret != 0) printf("FOUND %d\n", ret);
}

and

#!/bin/sh
for i in $(seq 1 200); do ./a.exe $i & done

but, no error was found...

How many cpu cores and how much memory does your system have?

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Fri, 1 Mar 2024 19:21:12 +0900
Takashi Yano wrote:
> On Fri, 1 Mar 2024 09:25:10 +0900
> Takashi Yano wrote:
> > On Thu, 29 Feb 2024 18:19:45 +
> > Kate Deplaix wrote:
> > > To reproduce this:
> > > 
> > >   *
> > > make sure you have a fresh installed of cygwin 3.5.1
> > >   *
> > > install the following packages: autoconf, make, patch, curl, 
> > > mingw64-x86_64-gcc-g++, mingw64-i686-gcc-g++
> > >   *
> > > curl -LO 
> > > https://github.com/ocaml/opam/releases/download/2.2.0-beta1/opam-full-2.2.0-beta1.tar.gz
> > >   *   tar xvf opam-full-2.2.0-beta1.tar.gz
> > >   *   cd opam-full-2.2.0-beta1
> > >   *   make cold
> > 
> > I tried to reproduce this, however, make cold failed with the error:
> [...]
> > ** Fatal error: Cannot run cygpath -m
> 
> I could reproduce the issue in Windows SandBox and might find the cause.
> I'll submit a patch for this issue shortly. Thanks for the report.

Please try: cygwin 3.6.0-0.66.gc77a5689f7bd (TEST)

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Fri, 1 Mar 2024 09:25:10 +0900
Takashi Yano wrote:
> On Thu, 29 Feb 2024 18:19:45 +
> Kate Deplaix wrote:
> > To reproduce this:
> > 
> >   *
> > make sure you have a fresh installed of cygwin 3.5.1
> >   *
> > install the following packages: autoconf, make, patch, curl, 
> > mingw64-x86_64-gcc-g++, mingw64-i686-gcc-g++
> >   *
> > curl -LO 
> > https://github.com/ocaml/opam/releases/download/2.2.0-beta1/opam-full-2.2.0-beta1.tar.gz
> >   *   tar xvf opam-full-2.2.0-beta1.tar.gz
> >   *   cd opam-full-2.2.0-beta1
> >   *   make cold
> 
> I tried to reproduce this, however, make cold failed with the error:
[...]
> ** Fatal error: Cannot run cygpath -m

I could reproduce the issue in Windows SandBox and might find the cause.
I'll submit a patch for this issue shortly. Thanks for the report.

-- 
Takashi Yano 

-- 
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

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

[Takashi Yano via Cygwin]

On Thu, 29 Feb 2024 18:19:45 +
Kate Deplaix wrote:
> To reproduce this:
> 
>   *
> make sure you have a fresh installed of cygwin 3.5.1
>   *
> install the following packages: autoconf, make, patch, curl, 
> mingw64-x86_64-gcc-g++, mingw64-i686-gcc-g++
>   *
> curl -LO 
> https://github.com/ocaml/opam/releases/download/2.2.0-beta1/opam-full-2.2.0-beta1.tar.gz
>   *   tar xvf opam-full-2.2.0-beta1.tar.gz
>   *   cd opam-full-2.2.0-beta1
>   *   make cold
> 
>   *
>   *

I tried to reproduce this, however, make cold failed with the error:

Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
   cygpath [-c HANDLE]
   cygpath [-ADHOPSW]
   cygpath [-F ID]

Convert Unix and Windows format paths, or output system path information

Output type options:

  -d, --dos print DOS (short) form of NAMEs (C:\PROGRA~1\)
  -m, --mixed   like --windows, but with regular slashes (C:/WINNT)
  -M, --modereport on mode of file (binmode or textmode)
  -u, --unix(default) print Unix form of NAMEs (/cygdrive/c/winnt)
  -w, --windows print Windows form of NAMEs (C:\WINNT)
  -t, --type TYPE   print TYPE form: 'dos', 'mixed', 'unix', or 'windows'

Path conversion options:

  -a, --absoluteoutput absolute path
  -l, --long-name   print Windows long form of NAMEs (with -w, -m only)
  -p, --pathNAME is a PATH list (i.e., '/bin:/usr/bin')
  -U, --proc-cygdrive   Emit /proc/cygdrive path instead of cygdrive prefix
when converting Windows path to UNIX path.
  -s, --short-name  print DOS (short) form of NAMEs (with -w, -m only)
  -C, --codepage CP print DOS, Windows, or mixed pathname in Windows
codepage CP.  CP can be a numeric codepage identifier,
or one of the reserved words ANSI, OEM, or UTF8.
If this option is missing, cygpath defaults to the
character set defined by the current locale.

System information:

  -A, --allusersuse `All Users' instead of current user for -D, -O, -P
  -D, --desktop output `Desktop' directory and exit
  -H, --homerootoutput `Profiles' directory (home root) and exit
  -O, --mydocs  output `My Documents' directory and exit
  -P, --smprograms  output Start Menu `Programs' directory and exit
  -S, --sysdir  output system directory and exit
  -W, --windir  output `Windows' directory and exit
  -F, --folder ID   output special folder with numeric ID and exit
Try `cygpath --help' for more information.
** Fatal error: Cannot run cygpath -m

Any idea?

-- 
Takashi Yano 

-- 
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

Re: cl: on failure - there is no shell error code returned with cygwin-3.5.0-1

[Takashi Yano via Cygwin]

On Thu, 22 Feb 2024 11:46:39 +0530 (IST)
Satish Balay wrote:
> Usage: Invoke 'cl' from cygwin/bash. i.e:
> 
> - run 'Visual Studio CMD' to setup MS compilers in dos shell
> - run 'c:\cygwin64\cygwin.bat' [or 'c:\cygwin64\bin\bash --login']
> - run 'cl /c test.c'
> 
> With cygwin upgrade to 3.5.0-1 - I'm not seeing "error return codes" on 
> compile failures.
> 
> However - this works again after downgrading to 3.4.10-1.
> 
> Note: This works with 3.5.0-1 - if I use 'mintty' - instead of 'cygwin.bat' 
> or 'bash --login' from 'Compiler CMD'
> 
> Perhaps a bug in current cygwin release?
> 
> thanks,
> Satish
> 
> 
> C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash 
> --login
> 
> balay@ps5 ~
> $ uname -a
> CYGWIN_NT-10.0-22631 ps5 3.5.0-1.x86_64 2024-02-01 11:02 UTC x86_64 Cygwin
> 
> balay@ps5 ~
> $ cat test.c
> error
> 
> balay@ps5 ~
> $ cl /c test.c
> Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> test.c
> test.c(2): fatal error C1004: unexpected end-of-file found
> 
> balay@ps5 ~
> $ echo $?
> 0
> 
> C:\Program Files\Microsoft Visual Studio\2022\Community>\cygwin64\bin\bash 
> --login
> 
> balay@ps5 ~
> $ uname -a
> CYGWIN_NT-10.0-22631 ps5 3.4.10-1.x86_64 2023-11-29 12:12 UTC x86_64 Cygwin
> 
> balay@ps5 ~
> $ cl test.c
> Microsoft (R) C/C++ Optimizing Compiler Version 19.38.33134 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> test.c
> test.c(2): fatal error C1004: unexpected end-of-file found
> 
> balay@ps5 ~
> $ echo $?
> 2
> 

Thanks for the report.
This bug has already has been fixed in current git head and will be
fixed in 3.5.1.

https://cygwin.com/pipermail/cygwin-patches/2024q1/012612.html

-- 
Takashi Yano 

-- 
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

Re: python3 3.9.18-1 hanging

[Takashi Yano via Cygwin]

On Tue, 30 Jan 2024 11:18:37 +0100
Marco Atzeri wrote:
> On 30/01/2024 10:22, Andrew Murray via Cygwin wrote:
> > Hi,
> > 
> > Over in Pillow’s GitHub Actions, the Cygwin job has started hanging when 
> > running pytest - 
> > https://github.com/python-pillow/Pillow/actions/runs/7690866578/job/20955296663
> > 
> > Interestingly, this is not something specific to Pillow. Cygwin has also 
> > been hanging for NumPy’s GitHub Actions, 
> > https://github.com/numpy/numpy/issues/25708, and GitPython, 
> > https://github.com/gitpython-developers/GitPython/pull/1814.
> > 
> > The conclusion that these Python developers have come to is that the 
> > problem started when Cygwin’s python3 package updated to 3.9.18-1. For the 
> > moment, they have downgraded to 3.9.16-1.
> > 
> > However, I’m letting you know here about the problem, in case you would 
> > like to find a more permanent solution.
> > 
> > Thanks
> > 
> 
> thanks,
> I will look
> 
> of course as soon I removed from test the problem raised

I hit probably the same issue while building pango1.0 1.51.2-1
with python39 3.9.18-2 (Test) installed.

Several python3.9 processes are stalled and some of them cannot
be terminated even with kill -9.

Attaching gdb to them shows SIGSEGV in the thread whose stack
is corrupted. The program counter is 0 as follows. Null function
pointer dereference?

Thread 12 "python3.9" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 19184.0x18ac]
0x in ?? ()

Another thread seems to stop in exit_thread() (winsup/cygwin/sigproc.cc).
It may be due to SEGV.

Downgrading it to 3.9.16-1 solves the issue.

-- 
Takashi Yano 

-- 
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

Re: Test: gcc-12.3.1+20240202-0.1

[Takashi Yano via Cygwin]

On Mon, 5 Feb 2024 06:27:43 +0900
Takashi Yano wrote:
> On Sun, 04 Feb 2024 21:52:46 +0100
> ASSI  wrote:
> > The native Gcc compilers have been updated to the latest upstream
> > snapshot version of the gcc-12 branch:
> > 
> >  gcc-12.3.1+20240202
> > 
> > This build incorporates the experimental v4 patch to use the newlib
> > locale function in libstdc++ so that other locales (aside from "C")
> > become usable.
> > 
> > Cygwin does not allow multiple versions of the compilers to be installed
> > concurrently.
> > 
> > For this build, the D compiler has been disabled since it does not
> > bootstrap due to the missing Phobos runtime on Cygwin.  No testing
> > beyond the compiler testsuite has been done.
> 
> Thank you for releasing this test version!
> 
> Does not this include AVX2 misalignd patch for
> https://cygwin.com/pipermail/cygwin/2023-December/255073.html

I mean:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0200-add-m-no-align-vector-insn-option-for-i386.patch

Please note that this patch adds MASK_NO_ALIGN_VECTOR_INSN to
TARGET_SUBTARGET_DEFAULT in mingw32.h, so adding similar to
cygming.h is necessary for cygwin build.

> introduced by lazka on IRC and GTHREAD mutex_init patch
> https://cygwin.com/pipermail/cygwin/2024-January/255203.html
> ?


-- 
Takashi Yano 

-- 
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

Re: Test: gcc-12.3.1+20240202-0.1

[Takashi Yano via Cygwin]

On Sun, 04 Feb 2024 21:52:46 +0100
ASSI  wrote:
> The native Gcc compilers have been updated to the latest upstream
> snapshot version of the gcc-12 branch:
> 
>  gcc-12.3.1+20240202
> 
> This build incorporates the experimental v4 patch to use the newlib
> locale function in libstdc++ so that other locales (aside from "C")
> become usable.
> 
> Cygwin does not allow multiple versions of the compilers to be installed
> concurrently.
> 
> For this build, the D compiler has been disabled since it does not
> bootstrap due to the missing Phobos runtime on Cygwin.  No testing
> beyond the compiler testsuite has been done.

Thank you for releasing this test version!

Does not this include AVX2 misalignd patch for
https://cygwin.com/pipermail/cygwin/2023-December/255073.html
introduced by lazka on IRC and GTHREAD mutex_init patch
https://cygwin.com/pipermail/cygwin/2024-January/255203.html
?

-- 
Takashi Yano 

-- 
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

Re: New package: btop 1.3.0-1

[Takashi Yano via Cygwin]

On Sat, 27 Jan 2024 08:58:49 +0900
Takashi Yano wrote:
> On Fri, 26 Jan 2024 16:09:10 -0700
> Brian Inglis wrote:
> > Window blips and disappears whether running from XDG Menu btop++ or 
> > terminal!
> 
> What happens if you run btop in mintty or UXterm?

I could reproduce the problem. I'll release 1.3.0-2.

Thanks!

-- 
Takashi Yano 

-- 
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

Re: New package: btop 1.3.0-1

[Takashi Yano via Cygwin]

On Fri, 26 Jan 2024 16:09:10 -0700
Brian Inglis wrote:
> Window blips and disappears whether running from XDG Menu btop++ or terminal!

What happens if you run btop in mintty or UXterm?

> tail ~/.xsession-errors
> ...
> executing 'xterm -e btop', pid 23052
> (pid 23052 stderr) Missing charset KSC5601.1987-0 for fallback fontset

This is not from btop, but from xterm. Just running xterm causes
the same message.

> pid 23052 exited with status 0
> executing 'xterm -e btop', pid 23056
> (pid 23056 stderr) Missing charset KSC5601.1987-0 for fallback fontset
> pid 23056 exited with status 0
> executing 'xterm -e btop', pid 23058
> (pid 23058 stderr) Missing charset KSC5601.1987-0 for fallback fontset
> pid 23058 exited with status 0
> 
> Why would I need legacy Korean character set encoding support not included in 
> or 
> required by the package?
> Apparently this charset used to be supported by font-daewoo-misc, which has 
> been 
> obsoleted by xorg-x11-fonts-misc, none of which support this legacy charset, 
> which may have been because of Fedora licensing concerns:
> Alternatives are labelled UHC or CP949 and modern replacement appears to be 
> EUC-KR.
> 
> https://sigwait.org/~alex/blog/2021/05/25/missing-charsets-in-string-to-fontset-conversion.html
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1952723
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-2021-4883dec0ce
> 
>   https://gitlab.freedesktop.org/xorg/font/daewoo-misc/-/issues/1
> 
> https://gitlab.freedesktop.org/xorg/font/bh-lucidatypewriter-100dpi/-/issues/1
> 
>   https://github.com/gromnitsky/rpm/blob/master/daewoo-misc-fonts/pkg.spec
> 
>   https://github.com/kisli/vmime/issues/216
> 
> https://stackoverflow.com/questions/13798461/how-to-normalize-encoding-names-like-ks-c-5601-1987-to-cp949
> 
> Anything we can do in fontconfig and/or require from some other package that 
> will alias the charset encoding and satisfy that requirement, or do we need a 
> new build or patched release that removes that requirement?

Thomas, any idea?

-- 
Takashi Yano 

-- 
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

Re: [ANNOUNCEMENT] Updated: xterm 380

[Takashi Yano via Cygwin]

On Mon, 15 May 2023 21:10:27 +0200
Thomas Wolff wrote:
> I have uploaded xterm 380.
> Major changes:
> 
>   * DEC VT320 status line support
>   * improved calculation of dim attribute colour

xterm 380 has a bug that wide bitmap fonts cannot be displayed correctly.
https://invisible-island.net/xterm/xterm.log.html#xterm_381

Could you please update xterm package?

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

On Mon, 22 Jan 2024 19:24:52 -0800
Kaz Kylheku wrote:
> On 2024-01-19 20:18, Takashi Yano via Cygwin wrote:
> > And I tried to observe the pthread_mutex_xxx() call. Then found the
> > test case does like:
> > 
> > #include 
> > int main()
> > {
> >   for (;;) {
> > pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
> > pthread_mutex_lock(&m);
> > pthread_mutex_unlock(&m);
> >   }
> >   return 0;
> > }
> 
> Note POSIX:
> 
> In cases where default mutex attributes are appropriate,
> the macro PTHREAD_MUTEX_INITIALIZER can be used to initialize
> mutexes. The effect shall be equivalent to dynamic initialization
> by a call to pthread_mutex_init() with parameter attr specified as NULL,
> except that no error checks are performed.
> 
> Thus, the following is correct:
> 
>for (;;) {
>  pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
>  pthread_mutex_lock(&m);
>  pthread_mutex_unlock(&m);
>  pthread_mutex_destroy(&m); // <--- added
>}
> 
> Does your above code leak if you add the destroy call?

No.

> If so, pthread_mutex_destroy needs to be fixed.
> 
> Either way, libstdc++ should be calling pthread_mutex_destroy
> in the destructor, in spite of initializing the object with
> a simple initializer.

Are there any code examples that use PTHREAD_MUTEX_INITIALIZER
with pthread_mutex_destroy()?

> That libstdc++ library could be fixed in the same way;
> the mutex object's destructor should call pthread_mutex_destroy,
> even though the constructor didn't call pthread_mutex_init.
> 
> This is a "moral equivalent":
> 
>   class buf {
> unsigned char *ptr;
>   public:
> buf() : ptr(NULL) { }
> ~buf() { delete [] ptr; }
> // ...
>   };
> 
> Just because you have a constructor that trivially initializes
> some resource with a constant expression doesn't mean that the
> destructor has nothing to free. In between there the object
> is mutated so that it holds resources.
> 
> 
> > POSIX states pthread_mutex_t can be initialized with
> > PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.
> 
> I'm looking at this and don't see such a constraint:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_destroy.html
> 
> The word "static" only occurs in the Rationale section.
> 
> Use of the initializer is not restricted to static objects
> by any normative wording.

It seems that I had read the older POSIX document.

https://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html

> In real systems, the static distinction has no meaning.
> 
> This code can be inside a shared library:
> 
>static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> 
> this library could be loaded by dlopen and unloaded with dlclose.
> Thus static becomes dynamic!
> 
> And, by the way, this is a problem: if we have a library
> which does the above, and we repeatedly load it and unload
> it while using the mutex in between, it will leak.

As you pointed out, if dlopen()/dlclose() are called repeatedly,
handle leak might occur even if pthread_mutex_t is statically
allocated.

> I think you don't want to do this kind of initialization in
> reloadable plugins, unless you put in some destructor hooks,
> or wrap it with C++ objects with destructors.


-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

On Mon, 22 Jan 2024 10:57:48 +0100
Corinna Vinschen wrote:
> On Jan 22 10:25, Corinna Vinschen via Cygwin wrote:
> > On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > > PATCH2: (for cygwin)
> > > Avoid handle leak caused when non-static pthread_once_t is initialized
> > > with PTHREAD_ONCE_INIT
> > > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > > index 7bb4f9fc8..127569160 100644
> > > --- a/winsup/cygwin/thread.cc
> > > +++ b/winsup/cygwin/thread.cc
> > > @@ -2060,6 +2060,9 @@ pthread::once (pthread_once_t *once_control, void 
> > > (*init_routine) (void))
> > >  {
> > >init_routine ();
> > >once_control->state = 1;
> > > +  pthread_mutex_unlock (&once_control->mutex);
> > > +  while (pthread_mutex_destroy (&once_control->mutex) == EBUSY);
> > > +  return 0;
> > >  }
> > >/* Here we must remove our cancellation handler */
> > >pthread_mutex_unlock (&once_control->mutex);
> > 
> > I see what you're doing here.  Wouldn't it be simpler, though, to do this?
> > 
> > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > index 7bb4f9fc8341..7ec3aace395d 100644
> > --- a/winsup/cygwin/thread.cc
> > +++ b/winsup/cygwin/thread.cc
> > @@ -2063,6 +2063,7 @@ pthread::once (pthread_once_t *once_control, void 
> > (*init_routine) (void))
> >  }
> >/* Here we must remove our cancellation handler */
> 
> Strange enough, this comment accompanies the code since its inception
> in 2001.  It says explicitly "remove" the cancellation handler.
> That sounds like the idea was right, just the programmer forgot about
> it afterwards...

I am not sure what 'cancellation handler' means here. Is it the
event handler in pthread_mutex_t?

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

On Mon, 22 Jan 2024 10:25:28 +0100
Corinna Vinschen wrote:
> On Jan 22 12:30, Takashi Yano via Cygwin wrote:
> > PATCH2: (for cygwin)
> > Avoid handle leak caused when non-static pthread_once_t is initialized
> > with PTHREAD_ONCE_INIT
> > diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> > index 7bb4f9fc8..127569160 100644
> > --- a/winsup/cygwin/thread.cc
> > +++ b/winsup/cygwin/thread.cc
> > @@ -2060,6 +2060,9 @@ pthread::once (pthread_once_t *once_control, void 
> > (*init_routine) (void))
> >  {
> >init_routine ();
> >once_control->state = 1;
> > +  pthread_mutex_unlock (&once_control->mutex);
> > +  while (pthread_mutex_destroy (&once_control->mutex) == EBUSY);
> > +  return 0;
> >  }
> >/* Here we must remove our cancellation handler */
> >pthread_mutex_unlock (&once_control->mutex);
> 
> I see what you're doing here.  Wouldn't it be simpler, though, to do this?
> 
> diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
> index 7bb4f9fc8341..7ec3aace395d 100644
> --- a/winsup/cygwin/thread.cc
> +++ b/winsup/cygwin/thread.cc
> @@ -2063,6 +2063,7 @@ pthread::once (pthread_once_t *once_control, void 
> (*init_routine) (void))
>  }
>/* Here we must remove our cancellation handler */
>pthread_mutex_unlock (&once_control->mutex);
> +  while (pthread_mutex_destroy (&once_control->mutex) == EBUSY);
>return 0;
>  }

In this code, if several threads call pthread_once() at the same time,
only one thread will succeed pthread_mutex_destroy() and the others
will fail with EINVAL. But it does not matter. The code will be
simpler.

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

On Sun, 21 Jan 2024 14:30:00 +0100
ASSI wrote:
> Takashi Yano via Cygwin writes:
> > I found the cause. In pthread.h of cygwin, PTHREAD_ONCE_INIT is defined as:
> > #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
> > however, libstdc++ initializes non-static pthread_once_t using this macro.
> 
> https://www.ibm.com/docs/en/aix/7.3?topic=p-pthread-once-init-macro
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_once.html
> 
> "The behavior of pthread_once() is undefined if once_control has
> automatic storage duration or is not initialized by PTHREAD_ONCE_INIT."
> 
> > I cannot find the POSIX statement that only static pthread_once_t can be
> > initialized using PTHREAD_ONCE_INIT. If I do not overlook something,
> > this is the problem of cygwin side, isn't it?
> 
> You can initialize just about anything with PTHREAD_ONCE_INIT, but you
> cannot expect the resulting structure to work as intended if there is
> more than instance per library / program, so the libstdc++ object should
> be a singleton, not automatic.
> 
> Still looks like ATWIL to me…

Thanks for the information.

Anyway, I confirmed the two patches (one is for gcc, the other is for cygwin)
resolve the issue.

PATCH1: (for gcc)
Do not use PTHREAD_MUTEX_INITIALIZER etc. for non-static pthread_mutex_t.
diff -ur origsrc/gcc-13-20230902/libgcc/gthr-posix.h 
src/gcc-13-20230902/libgcc/gthr-posix.h
--- origsrc/gcc-13-20230902/libgcc/gthr-posix.h 2023-09-03 07:32:49.0 
+0900
+++ src/gcc-13-20230902/libgcc/gthr-posix.h 2024-01-22 09:04:54.342189600 
+0900
@@ -34,6 +34,12 @@
 
 #include 
 
+#ifdef __CYGWIN__
+#define _GTHREAD_USE_MUTEX_INIT_FUNC 1
+#define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC 1
+#define _GTHREAD_USE_COND_INIT_FUNC 1
+#endif
+
 #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \
  || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK))
 # include 


PATCH2: (for cygwin)
Avoid handle leak caused when non-static pthread_once_t is initialized
with PTHREAD_ONCE_INIT
diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 7bb4f9fc8..127569160 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -2060,6 +2060,9 @@ pthread::once (pthread_once_t *once_control, void 
(*init_routine) (void))
 {
   init_routine ();
   once_control->state = 1;
+  pthread_mutex_unlock (&once_control->mutex);
+  while (pthread_mutex_destroy (&once_control->mutex) == EBUSY);
+  return 0;
 }
   /* Here we must remove our cancellation handler */
   pthread_mutex_unlock (&once_control->mutex);

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

Hi Corinna,

On Sat, 20 Jan 2024 21:24:27 +0900
Takashi Yano wrote:
> On Sat, 20 Jan 2024 10:13:22 +0100
> ASSI wrote:
> > Takashi Yano via Cygwin writes:
> > > I might find the culprit in gcc's libstdc++ code such as:
> > > libstdc++-v3/include/ext/concurrentce.h:
> > >   class __mutex
> > >   {
> > >   private:
> > > #if __GTHREADS && defined __GTHREAD_MUTEX_INIT
> > > __gthread_mutex_t _M_mutex = __GTHREAD_MUTEX_INIT;
> > > #else
> > > __gthread_mutex_t _M_mutex;
> > > #endif
> > >
> > > __GTHREAD_MUTEX_INIT here is PTHREAD_MUTEX_INITIALIZER and
> > > __gthread_mutex_t is pthread_mutex_t.
> > >
> > > I think this code vaiolates the POSIX statement.
> > 
> > So what happens if you undefine __GTHREAD_MUTEX_INIT?
> 
> I have tried. The test case:
> #include 
> int main()
> {
>   for (;;) {
> std::mutex *m = new std::mutex;
> m->lock();
> m->unlock();
> delete m;
>   }
>   return 0;
> }
> gets working fine. However, this test case:
> #include 
> int func() { return 0; }
> int main()
> {
>   for (;;) {
> std::future f = std::async(std::launch::async, func);
> f.get();
>   }
>   return 0;
> }
> still has the problem.
> 
> pthread_mutex_t might be initialized also at another place...

I found the cause. In pthread.h of cygwin, PTHREAD_ONCE_INIT is defined as:
#define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
however, libstdc++ initializes non-static pthread_once_t using this macro.

I cannot find the POSIX statement that only static pthread_once_t can be
initialized using PTHREAD_ONCE_INIT. If I do not overlook something,
this is the problem of cygwin side, isn't it?

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

On Sat, 20 Jan 2024 10:13:22 +0100
ASSI wrote:
> Takashi Yano via Cygwin writes:
> > I might find the culprit in gcc's libstdc++ code such as:
> > libstdc++-v3/include/ext/concurrentce.h:
> >   class __mutex
> >   {
> >   private:
> > #if __GTHREADS && defined __GTHREAD_MUTEX_INIT
> > __gthread_mutex_t _M_mutex = __GTHREAD_MUTEX_INIT;
> > #else
> > __gthread_mutex_t _M_mutex;
> > #endif
> >
> > __GTHREAD_MUTEX_INIT here is PTHREAD_MUTEX_INITIALIZER and
> > __gthread_mutex_t is pthread_mutex_t.
> >
> > I think this code vaiolates the POSIX statement.
> 
> So what happens if you undefine __GTHREAD_MUTEX_INIT?

I have tried. The test case:
#include 
int main()
{
  for (;;) {
std::mutex *m = new std::mutex;
m->lock();
m->unlock();
delete m;
  }
  return 0;
}
gets working fine. However, this test case:
#include 
int func() { return 0; }
int main()
{
  for (;;) {
std::future f = std::async(std::launch::async, func);
f.get();
  }
  return 0;
}
still has the problem.

pthread_mutex_t might be initialized also at another place...


-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

Hi Corinna and Achim,

On Sat, 20 Jan 2024 13:18:25 +0900
Takashi Yano wrote:
> Hi Corinna,
> 
> On Fri, 19 Jan 2024 15:28:40 +0100
> Corinna Vinschen wrote:
> > On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> > > Hi,
> > > 
> > > I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> > > The following test case (c++ code) causes handle leak.
> > > 
> > > This issue is reproducible with both g++ and clang++.
> > > However, it does not happen in Linux environment.
> > > So I guess this is the cygwin1.dlll bug.
> > > 
> > > I looked into this problem a bit, and found number of event handle
> > > increases every loop.
> > > 
> > > I doubt pthread_mutex_xxx functions.
> > > 
> > > #include 
> > > int func() { return 0; }
> > > int main()
> > > {
> > >   for (;;) {
> > > std::future f = std::async(std::launch::async, func);
> > > f.get();
> > >   }
> > >   return 0;
> > > }
> > 
> > Can you create a plain C testcase from there?  It's much easier to
> > debug.
> 
> I could symplify the test case:
> #include 
> int main()
> {
>   for (;;) {
> std::mutex *m = new std::mutex;
> m->lock();
> m->unlock();
> delete m;
>   }
>   return 0;
> }
> 
> And I tried to observe the pthread_mutex_xxx() call. Then found the
> test case does like:
> 
> #include 
> int main()
> {
>   for (;;) {
> pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
> pthread_mutex_lock(&m);
> pthread_mutex_unlock(&m);
>   }
>   return 0;
> }
> 
> POSIX states pthread_mutex_t can be initialized with
> PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.
> 
> In this case, m is not static. So it seems that this is
> a bug of libstdc++. However, the plain c code above works
> in Linux without problems even with non-static mutex m.
> 
> I guess it is very difficult to make the plain c code above
> work in cygwin, because cygwin can not know when cygwin can
> discard the mutex resources...

I might find the culprit in gcc's libstdc++ code such as:
libstdc++-v3/include/ext/concurrentce.h:
  class __mutex
  {
  private:
#if __GTHREADS && defined __GTHREAD_MUTEX_INIT
__gthread_mutex_t _M_mutex = __GTHREAD_MUTEX_INIT;
#else
__gthread_mutex_t _M_mutex;
#endif

__GTHREAD_MUTEX_INIT here is PTHREAD_MUTEX_INITIALIZER and
__gthread_mutex_t is pthread_mutex_t.

I think this code vaiolates the POSIX statement.

-- 
Takashi Yano 

-- 
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

Re: Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

Hi Corinna,

On Fri, 19 Jan 2024 15:28:40 +0100
Corinna Vinschen wrote:
> On Jan 19 22:44, Takashi Yano via Cygwin wrote:
> > Hi,
> > 
> > I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
> > The following test case (c++ code) causes handle leak.
> > 
> > This issue is reproducible with both g++ and clang++.
> > However, it does not happen in Linux environment.
> > So I guess this is the cygwin1.dlll bug.
> > 
> > I looked into this problem a bit, and found number of event handle
> > increases every loop.
> > 
> > I doubt pthread_mutex_xxx functions.
> > 
> > #include 
> > int func() { return 0; }
> > int main()
> > {
> >   for (;;) {
> > std::future f = std::async(std::launch::async, func);
> > f.get();
> >   }
> >   return 0;
> > }
> 
> Can you create a plain C testcase from there?  It's much easier to
> debug.

I could symplify the test case:
#include 
int main()
{
  for (;;) {
std::mutex *m = new std::mutex;
m->lock();
m->unlock();
delete m;
  }
  return 0;
}

And I tried to observe the pthread_mutex_xxx() call. Then found the
test case does like:

#include 
int main()
{
  for (;;) {
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);
  }
  return 0;
}

POSIX states pthread_mutex_t can be initialized with
PTREAD_MUTEX_INITIALZER when it is STATICALLY allocated.

In this case, m is not static. So it seems that this is
a bug of libstdc++. However, the plain c code above works
in Linux without problems even with non-static mutex m.

I guess it is very difficult to make the plain c code above
work in cygwin, because cygwin can not know when cygwin can
discard the mutex resources...

-- 
Takashi Yano 

-- 
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

Possiblly bug of cygwin1.dll

[Takashi Yano via Cygwin]

Hi,

I might find the bug of cygwin1.dll (including 3.4.x, 3.5.0 (TEST)).
The following test case (c++ code) causes handle leak.

This issue is reproducible with both g++ and clang++.
However, it does not happen in Linux environment.
So I guess this is the cygwin1.dlll bug.

I looked into this problem a bit, and found number of event handle
increases every loop.

I doubt pthread_mutex_xxx functions.

#include 
int func() { return 0; }
int main()
{
  for (;;) {
std::future f = std::async(std::launch::async, func);
f.get();
  }
  return 0;
}

-- 
Takashi Yano 

-- 
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