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

gnutls 3.8.6-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gnutls-3.8.6-1
* libgnutls30-3.8.6-1
* libgnutls-dane0-3.8.6-1
* libgnutlsxx30-3.8.6-1
* libgnutls-devel-3.8.6-1
* libgnutls-doc-3.8.6-1

GnuTLS is a secure communications library implementing the SSL,
TLS and DTLS protocols and technologies around them. It provides a simple C
language application programming interface (API) to access the secure
communications protocols as well as APIs to parse and write X.509, PKCS#12,
OpenPGP and other required structures.
-- 
  *** 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: 
.

gtk3 3.24.43-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gtk-update-icon-cache-3.24.43-1
* gtk3-demo-3.24.43-1
* libgtk3_0-3.24.43-1
* libgtk3-devel-3.24.43-1
* libgtk3-doc-3.24.43-1
* girepository-Gtk3.0-3.24.43-1
* libgailutil3_0-3.24.43-1
* libgailutil3-devel-3.24.43-1
* libgailutil3-doc-3.24.43-1

GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for projects
ranging from small one-off tools to complete application suites.
-- 
  *** 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: 
.

orc 0.4.39-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* liborc0.4_0-0.4.39-2
* liborc0.4-devel-0.4.39-2
* liborc0.4-doc-0.4.39-2

Orc is a library and set of tools for compiling and executing
very simple programs that operate on arrays of data.  The language
is a generic assembly language that represents many of the features
available in SIMD architectures, including saturated addition and
subtraction, and many arithmetic operations.

Fixes:
- Add workaround for alignment setting in byte-code compilation.
-- 
  *** 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: 
.

orc 0.4.39-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* liborc0.4_0-0.4.39-1
* liborc0.4-devel-0.4.39-1
* liborc0.4-doc-0.4.39-1

Orc is a library and set of tools for compiling and executing
very simple programs that operate on arrays of data.  The language
is a generic assembly language that represents many of the features
available in SIMD architectures, including saturated addition and
subtraction, and many arithmetic operations.
-- 
  *** 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: 
.

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

svt-av1 2.1.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* svt-av1-2.1.2-1
* libsvtav1enc2-2.1.2-1
* libsvtav1-devel-2.1.2-1
* libsvtav1-doc-2.1.2-1

The Scalable Video Technology for AV1 (SVT-AV1 Encoder) is an AV1-compliant 
software encoder library. The work on the SVT-AV1 encoder targets the 
development of a production-quality AV1-encoder with performance levels 
applicable to a wide range of applications, from premium VOD to real-time and 
live encoding/transcoding.


Upstream change:
- Removed the SVT-AV1 Decoder portion of the project. The last version
  containing the decoder is SVT-AV1 v2.1.0.

-- 
  *** 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: 
.

AMF 1.4.34-1

[Takashi Yano via Cygwin-announce]

The following package has been uploaded to the Cygwin distribution:

* AMF-1.4.34-1

A light-weight, portable multimedia framework that abstracts away most of the 
platform and API-specific details. AMF is supported on the closed source AMD 
Pro driver and OpenMax on the open source AMD Mesa driver, whose dlls are 
dynamically loaded by the SDK header. The codec itself is impelemted in the 
dlls and the AMD GPU.
-- 
  *** 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: 
.

SDL2 2.30.5-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.5-1
* libSDL2-devel-2.30.5-1

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.
-- 
  *** 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: 
.

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

libass 0.17.3-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libass9-0.17.3-1
* libass-devel-0.17.3-1

LibASS is a portable library for SSA/ASS (Substation Alpha)
subtitle rendering.
-- 
  *** 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: 
.

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:

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

pango1.0 1.54.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libpango1.0_0-1.54.0-1
* libpango1.0-devel-1.54.0-1
* libpango1.0-doc-1.54.0-1
* girepository-Pango1.0-1.54.0-1

Pango is a library for layout and rendering of text, with an emphasis
on internationalization. Pango can be used anywhere that text layout
is needed; however, most of the work on Pango so far has been done using
the GTK+ widget toolkit as a test platform. Pango forms the core of text
and font handling for GTK+.
-- 
  *** 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: 
.

libvpl 2.12.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libvpl-2.12.0-1
* libvpl-devel-2.12.0-1

This package provides the headers and the library which loads Intel MediaSDK 
dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU.
-- 
  *** 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: 
.

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

esound 0.2.41-13

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* esound-0.2.41-13
* libesd0-0.2.41-13
* libesd-devel-0.2.41-13
* esound-daemon-0.2.41-13

EsounD mixes multiple digitized audio streams and samples together
for playback by a single audio device. It also allows monitoring of mixed
output, and recording. Network connections to the daemon are supported as well.


- Let esd (daemon) comeback. esd had been replaced with pulseaudio-
  esound-compat package, however, it was dropped from current pluse-
  audio packaging. So, packaging esd (esound-daemon) has been enabled.
-- 
  *** 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: 
.

ffmpeg 7.0.1-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ffmpeg-7.0.1-2
* libavutil59-7.0.1-2
* libavcodec61-7.0.1-2
* libavformat61-7.0.1-2
* libavdevice61-7.0.1-2
* libavfilter10-7.0.1-2
* libswscale8-7.0.1-2
* libswresample5-7.0.1-2
* libpostproc58-7.0.1-2
* libavutil-devel-7.0.1-2
* libavcodec-devel-7.0.1-2
* libavformat-devel-7.0.1-2
* libavdevice-devel-7.0.1-2
* libavfilter-devel-7.0.1-2
* libswscale-devel-7.0.1-2
* libswresample-devel-7.0.1-2
* libpostproc-devel-7.0.1-2
* ffmpeg-examples-7.0.1-2
* ffmpeg-doc-7.0.1-2

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, 
mux, demux, stream and filter pretty much anything that humans and machines 
have created. It supports the most obscure ancient formats up to the cutting 
edge.


- Disable OpenCL. This makes ffmpeg free from clang dependency via pocl.


-- 
  *** 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: 
.

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: [ITA] esound

[Takashi Yano via Cygwin-apps]

On Thu, 20 Jun 2024 12:37:20 +0900
Takashi Yano  wrote:
> HOMEPAGE="http://www.tux.org/~ricdude/EsounD.html;

Ah, HOMEPAGE should be
https://ftp.gnome.org/pub/GNOME/sources/esound

-- 
Takashi Yano 

[ITA] esound

[Takashi Yano via Cygwin-apps]

esound itself has not been changed, however, pulseaudio package
dropped pluseaudio-esound-compat in 15.0 and later.
Therefore, I would like esd (daemon) to comeback in esound
package.

-- 
Takashi Yano 
inherit gnome.org

NAME="esound"
VERSION=0.2.41
RELEASE=13
CATEGORY="Audio"
LICENSE="LGPL-2.0-or-later"
SUMMARY="Enlightened Sound Daemon clients"
DESCRIPTION="EsounD mixes multiple digitized audio streams and samples together
for playback by a single audio device. It also allows monitoring of mixed
output, and recording. Network connections to the daemon are supported as well."
HOMEPAGE="http://www.tux.org/~ricdude/EsounD.html;

PKG_NAMES="${NAME} libesd0 libesd-devel esound-daemon"
esound_REQUIRES="esound-daemon"
esound_CONTENTS="--exclude=*-config* --exclude=aclocal 
--exclude=usr/bin/esd.exe --exclude usr/share/man/man1/esd.1* usr/bin/*.exe 
usr/share/"
libesd0_SUMMARY="${SUMMARY%s} library (runtime)"
libesd0_CONTENTS="usr/bin/cygesd-0.dll"
libesd_devel_SUMMARY="${SUMMARY%s} library (development)"
libesd_devel_CONTENTS="usr/bin/esd-config usr/include/ usr/lib/ 
usr/share/aclocal/
   usr/share/man/man1/esd-config.*"
esound_daemon_CONTENTS="usr/bin/esd.exe usr/share/man/man1/esd.1* etc/esd.conf"
esound_daemon_SUMMARY="${SUMMARY%s} daemon"

DIFF_EXCLUDES="esddsp"

SDL2 2.30.4-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.4-1
* libSDL2-devel-2.30.4-1

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.
-- 
  *** 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: 
.

dav1d 1.4.3-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* dav1d-1.4.3-1
* libdav1d7-1.4.3-1
* libdav1d-devel-1.4.3-1

dav1d is a new AV1 cross-platform Decoder, open-source, and focused on speed 
and correctness.
-- 
  *** 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: 
.

aom 3.9.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* aom-3.9.1-1
* libaom3-3.9.1-1
* libaom-devel-3.9.1-1


-- 
  *** 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: 
.

ffmpeg 7.0.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ffmpeg-7.0.1-1
* libavutil59-7.0.1-1
* libavcodec61-7.0.1-1
* libavformat61-7.0.1-1
* libavdevice61-7.0.1-1
* libavfilter10-7.0.1-1
* libswscale8-7.0.1-1
* libswresample5-7.0.1-1
* libpostproc58-7.0.1-1
* libavutil-devel-7.0.1-1
* libavcodec-devel-7.0.1-1
* libavformat-devel-7.0.1-1
* libavdevice-devel-7.0.1-1
* libavfilter-devel-7.0.1-1
* libswscale-devel-7.0.1-1
* libswresample-devel-7.0.1-1
* libpostproc-devel-7.0.1-1
* ffmpeg-examples-7.0.1-1
* ffmpeg-doc-7.0.1-1

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, 
mux, demux, stream and filter pretty much anything that humans and machines 
have created. It supports the most obscure ancient formats up to the cutting 
edge.
-- 
  *** 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: 
.

ffmpeg 7.0-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ffmpeg-7.0-2
* libavutil59-7.0-2
* libavcodec61-7.0-2
* libavformat61-7.0-2
* libavdevice61-7.0-2
* libavfilter10-7.0-2
* libswscale8-7.0-2
* libswresample5-7.0-2
* libpostproc58-7.0-2
* libavutil-devel-7.0-2
* libavcodec-devel-7.0-2
* libavformat-devel-7.0-2
* libavdevice-devel-7.0-2
* libavfilter-devel-7.0-2
* libswscale-devel-7.0-2
* libswresample-devel-7.0-2
* libpostproc-devel-7.0-2
* ffmpeg-examples-7.0-2
* ffmpeg-doc-7.0-2

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, 
mux, demux, stream and filter pretty much anything that humans and machines 
have created. It supports the most obscure ancient formats up to the cutting 
edge.


- Enable dav1d (Fast av1 decoder)

-- 
  *** 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: 
.

pulseaudio 17.0-4

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* pulseaudio-17.0-4
* pulseaudio-equalizer-17.0-4
* pulseaudio-utils-17.0-4
* pulseaudio-module-x11-17.0-4
* pulseaudio-module-zeroconf-17.0-4
* pulseaudio-module-gsettings-17.0-4
* libpulse0-17.0-4
* libpulse-mainloop-glib0-17.0-4
* libpulse-simple0-17.0-4
* libpulse-devel-17.0-4
* libpulse-doc-17.0-4
* vala-libpulse-17.0-4

PulseAudio is a sound system for POSIX OSes, meaning that it is
a proxy for your sound applications. It allows you to do advanced operations
on your sound data as it passes between your application and your hardware.
Things like transferring the audio to a different machine, changing the sample
format or channel count and mixing several sounds into one are easily achieved
using a sound server.

- Re-enable ORC since the issue has been fixed on the ORC side.

-- 
  *** 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: 
.

[New] dav1d 1.4.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* dav1d-1.4.2-1
* libdav1d7-1.4.2-1
* libdav1d-devel-1.4.2-1

dav1d is a new AV1 cross-platform Decoder, open-source, and focused on speed 
and correctness.
-- 
  *** 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: 
.

orc 0.4.38-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* liborc0.4_0-0.4.38-2
* liborc0.4-devel-0.4.38-2
* liborc0.4-doc-0.4.38-2

Orc is a library and set of tools for compiling and executing
very simple programs that operate on arrays of data.  The language
is a generic assembly language that represents many of the features
available in SIMD architectures, including saturated addition and
subtraction, and many arithmetic operations.


- Fix incorrect code generation in JIT compiler.
-- 
  *** 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: 
.

pulseaudio 17.0-3

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* pulseaudio-17.0-3
* pulseaudio-equalizer-17.0-3
* pulseaudio-utils-17.0-3
* pulseaudio-module-x11-17.0-3
* pulseaudio-module-zeroconf-17.0-3
* pulseaudio-module-gsettings-17.0-3
* libpulse0-17.0-3
* libpulse-mainloop-glib0-17.0-3
* libpulse-simple0-17.0-3
* libpulse-devel-17.0-3
* libpulse-doc-17.0-3
* vala-libpulse-17.0-3

PulseAudio is a sound system for POSIX OSes, meaning that it is
a proxy for your sound applications. It allows you to do advanced operations
on your sound data as it passes between your application and your hardware.
Things like transferring the audio to a different machine, changing the sample
format or channel count and mixing several sounds into one are easily achieved
using a sound server.


- Disable ORC, which causes SEGV at volume control.
-- 
  *** 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: 
.

SDL2 2.30.3-2

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.3-2
* libSDL2-devel-2.30.3-2

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.

- Enable Direct3D renderer as well as X11. This allows faster rendering than
  X11 in some older environments.
-- 
  *** 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: 
.

[ITP] dav1d

[Takashi Yano via Cygwin-apps]

dav1d is a decoder for AV1 video codec, which is faster
as twice as libaom.

This package is available also for fedora.
https://src.fedoraproject.org/rpms/dav1d

I'am planning to release ffmpeg where dav1d is enabled
as fedora.

Thanks in advance.

-- 
Takashi Yano 
NAME=dav1d
VERSION=1.4.2
RELEASE=1
LICENSE="BSD-2-Clause AND ISC"
CATEGORY="Video"
SUMMARY="AV1 cross-platform decoder"
DESCRIPTION="dav1d is a new AV1 cross-platform Decoder, open-source, and 
focused on speed and correctness."
HOMEPAGE=https://code.videolan.org/videolan/dav1d
SRC_URI=https://code.videolan.org/videolan/dav1d/-/archive/${VERSION}/${NAME}-${VERSION}.tar.bz2

inherit meson

PKG_NAMES="dav1d libdav1d7 libdav1d-devel"
dav1d_CONTENTS="usr/bin/*.exe usr/share"
libdav1d7_CONTENTS="usr/bin/*.dll"
libdav1d_devel_CONTENTS="usr/lib usr/include"

BUILD_REQUIRES="nasm meson pkg-config libxxhash-devel"

fribidi 1.0.15-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* fribidi-1.0.15-1
* libfribidi0-1.0.15-1
* libfribidi-devel-1.0.15-1
* libfribidi-doc-1.0.15-1

A library that implements the Unicode Bidirectional Algorithm
(also knows as BiDi).
-- 
  *** 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: 
.

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 _control->state is int *, which is compatible with
> >  LONG * (the type of the pointer argument of InterlockedXxx()). */
> >   if ((InterlockedIncrement (_control->state) & done) == 0)
> > {
> >   pthread_mutex_lock (_control->mutex);
> >   if (!(once_control->state & done))
> > {
> >   init_routine ();
> >   InterlockedOr (_control->state, done);
> > }
> >   pthread_mutex_unlock (_control->mutex);
> > }
> >   InterlockedDecrement (_control->state);
> >   if (InterlockedCompareExchange (_control->state,
> >   destroyed, done) == done)
> > pthread_mutex_destroy (_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 _control->state is int *, which is compatible with
> >  LONG * (the type of the first argument of InterlockedIncrement()). */
> >   InterlockedIncrement (_control->state);
> >   pthread_mutex_lock (_control->mutex);
> >   if (!(once_control->state & INT_MIN))
> > {
> >   init_routine ();
> >   InterlockedOr (_control->state, INT_MIN);
> > }
> >   pthread_mutex_unlock (_control->mutex);
> >   if (InterlockedDecrement (_control->state) == INT_MIN)
> 
>   // HERE: Point B.
> 
> > pthread_mutex_destroy (_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 _control->state is int *, which is compatible with
 LONG * (the type of the pointer argument of InterlockedXxx()). */
  if ((InterlockedIncrement (_control->state) & done) == 0)
{
  pthread_mutex_lock (_control->mutex);
  if (!(once_control->state & done))
{
  init_routine ();
  InterlockedOr (_control->state, done);
}
  pthread_mutex_unlock (_control->mutex);
}
  InterlockedDecrement (_control->state);
  if (InterlockedCompareExchange (_control->state,
  destroyed, done) == done)
pthread_mutex_destroy (_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. Could you please check?

-- 
Takashi Yano 

-- 
Problem reports:  

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 (_control->mutex);
>   if (once_control->done == 0)
> {
>   (*initfunction) ();
>   once_control->done = 1;
> }
>   pthread_mutex_unlock (_control->mutex);
>   if ((once_control->num_threads -= 1) == 0)
> pthread_mutex_destroy (_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: Please update nasm package

[Takashi Yano via Cygwin-apps]

On Tue, 28 May 2024 07:50:08 +0900
Takashi Yano via Cygwin-apps  wrote:
> On Mon, 27 May 2024 21:18:08 +0200
> Michal Feix  wrote:
> > > I'm planning to submit ITP for dav1d
> > > https://code.videolan.org/videolan/dav1d
> > > and tried to build it on cygwin, however, it failed because
> > > nasm is too old. The current stable version is 2.16.03 while
> > > cygwin package version is 2.13.01.
> > > 
> > > Could the maintainer please update the nasm package?
> > 
> > Hi Takashi, I will have a look into this troghout the rest of this week.
> 
> Thanks for quick response!


I think it's unnecessary meddling,
v2.16.03 can be successfully built by the cygport file:

NAME="nasm"
VERSION=2.16.03
RELEASE=1
LICENSE="BSD 2-Clause"
CATEGORY="Devel"
SUMMARY="The Netwide Assembler"
DESCRIPTION="NASM is a widespread, portable, very flexible and mature
assembler tool with support for many output formats licensed under the
2-clause BSD licence."
HOMEPAGE="http://www.nasm.us/;
SRC_URI="http://www.nasm.us/pub/nasm/releasebuilds/${PV}/${P}.tar.xz;

src_compile() {
cd ${B}
cygconf
cygmake
}

-- 
Takashi Yano 

Re: Please update nasm package

[Takashi Yano via Cygwin-apps]

On Mon, 27 May 2024 21:18:08 +0200
Michal Feix  wrote:
> > I'm planning to submit ITP for dav1d
> > https://code.videolan.org/videolan/dav1d
> > and tried to build it on cygwin, however, it failed because
> > nasm is too old. The current stable version is 2.16.03 while
> > cygwin package version is 2.13.01.
> > 
> > Could the maintainer please update the nasm package?
> 
> Hi Takashi, I will have a look into this troghout the rest of this week.

Thanks for quick response!


-- 
Takashi Yano 

Please update nasm package

[Takashi Yano via Cygwin-apps]

Hi,

I'm planning to submit ITP for dav1d
https://code.videolan.org/videolan/dav1d
and tried to build it on cygwin, however, it failed because
nasm is too old. The current stable version is 2.16.03 while
cygwin package version is 2.13.01.

Could the maintainer please update the nasm package?

-- 
Takashi Yano 

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

snappy 1.2.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libsnappy1-1.2.1-1
* libsnappy-devel-1.2.1-1

Snappy is a compression/decompression library. It does not aim for
maximum compression, or compatibility with any other compression library,
instead, it aims for very high speeds and reasonable compression.
-- 
  *** 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: 
.

moc 2.6.r3005-5

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* moc-2.6.r3005-5
* moc-ffmpeg-plugin-2.6.r3005-5
* moc-timidity-plugin-2.6.r3005-5

MOC (Music on Console) is an audio player having the user interface similar to 
midnight commander. It supports verious audio formats with decoder plugins. 
Powerfull and easy to use.


Changes:

 - Add CUE sheet support as an original implementation of cygwin port
 - Fix for non-UTF8 locales
 - Skip BOM in playlist file
 - Improve seek accuracy of ffmpeg plugin
-- 
  *** 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: 
.

gtk3 3.24.42-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gtk-update-icon-cache-3.24.42-1
* gtk3-demo-3.24.42-1
* libgtk3_0-3.24.42-1
* libgtk3-devel-3.24.42-1
* libgtk3-doc-3.24.42-1
* girepository-Gtk3.0-3.24.42-1
* libgailutil3_0-3.24.42-1
* libgailutil3-devel-3.24.42-1
* libgailutil3-doc-3.24.42-1

GTK+ is a multi-platform toolkit for creating graphical user
interfaces. Offering a complete set of widgets, GTK+ is suitable for projects
ranging from small one-off tools to complete application suites.
-- 
  *** 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: 
.

fluidsynth 2.3.5-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* fluidsynth-2.3.5-1
* libfluidsynth3-2.3.5-1
* libfluidsynth-devel-2.3.5-1

FluidSynth is a real-time software synthesizer based on the
SoundFont 2 specifications.
-- 
  *** 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: 
.

libopenmpt 0.7.7-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libopenmpt0-0.7.7-1
* libopenmpt-devel-0.7.7-1
* openmpt123-0.7.7-1

libopenmpt is a cross-platform C++ and C library to decode tracked
music files (modules) into a raw PCM audio stream.
-- 
  *** 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: 
.

svt-av1 2.1.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* svt-av1-2.1.0-1
* libsvtav1enc2-2.1.0-1
* libsvtav1dec0-2.1.0-1
* libsvtav1-devel-2.1.0-1
* libsvtav1-doc-2.1.0-1

The Scalable Video Technology for AV1 (SVT-AV1 Encoder and Decoder) is an 
AV1-compliant software encoder/decoder library. The work on the SVT-AV1 encoder 
targets the development of a production-quality AV1-encoder with performance 
levels applicable to a wide range of applications, from premium VOD to 
real-time and live encoding/transcoding. The SVT-AV1 decoder implementation 
targets future codec research activities.
-- 
  *** 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: 
.

libass 0.17.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libass9-0.17.2-1
* libass-devel-0.17.2-1

LibASS is a portable library for SSA/ASS (Substation Alpha)
subtitle rendering.
-- 
  *** 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: 
.

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

unbound 1.20.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* unbound-1.20.0-1
* libunbound8-1.20.0-1
* libunbound-common-1.20.0-1
* libunbound-devel-1.20.0-1
* python3-unbound-1.20.0-1

Unbound is a validating, recursive, and caching DNS resolver.
Unbound is designed as a set of modular components, so that also DNSSEC
validation and stub-resolvers (that do not run as a server, but are linked
into an application) are easily possible.
-- 
  *** 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: 
.

ffmpeg 7.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ffmpeg-7.0-1
* libavutil59-7.0-1
* libavcodec61-7.0-1
* libavformat61-7.0-1
* libavdevice61-7.0-1
* libavfilter10-7.0-1
* libswscale8-7.0-1
* libswresample5-7.0-1
* libpostproc58-7.0-1
* libavutil-devel-7.0-1
* libavcodec-devel-7.0-1
* libavformat-devel-7.0-1
* libavdevice-devel-7.0-1
* libavfilter-devel-7.0-1
* libswscale-devel-7.0-1
* libswresample-devel-7.0-1
* libpostproc-devel-7.0-1
* ffmpeg-examples-7.0-1
* ffmpeg-doc-7.0-1

FFmpeg is the leading multimedia framework, able to decode, encode, transcode, 
mux, demux, stream and filter pretty much anything that humans and machines 
have created. It supports the most obscure ancient formats up to the cutting 
edge.
-- 
  *** 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: 
.

SDL2 2.30.3-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.3-1
* libSDL2-devel-2.30.3-1

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.
-- 
  *** 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: 
.

libvpl 2.11.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libvpl-2.11.0-1
* libvpl-devel-2.11.0-1

This package provides the headers and the library which loads Intel MediaSDK 
dlls dynamically. The codec itself is implemented in the dlls and the Intel GPU.
-- 
  *** 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: 
.

aom 3.9.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* aom-3.9.0-1
* libaom3-3.9.0-1
* libaom-devel-3.9.0-1


-- 
  *** 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: 
.

Re: [ITA] libkate

[Takashi Yano via Cygwin-apps]

On Sat, 27 Apr 2024 20:35:34 +0900
Takashi Yano wrote:
> Hi,
> 
> I would like to adopt libkate package.
> Thanks.

Sorry, the package seems to be already the latest version.
Update is not necessary so far.

-- 
Takashi Yano 

vorbis-tools 1.4.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* vorbis-tools-1.4.2-1

vorbis-tools contains oggenc (an encoder) and ogg123 (a playback tool).
It also has vorbiscomment (to add comments to vorbis files), ogginfo (to give
all useful information about an ogg file, including streams in it), oggdec (a
simple command line decoder), and vcut (which allows you to cut up vorbis
files).
-- 
  *** 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: 
.

[ITA] libkate

[Takashi Yano via Cygwin-apps]

Hi,

I would like to adopt libkate package.
Thanks.

-- 
Takashi Yano 

speexdsp 1.2.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* speexdsp-1.2.1-1
* speexdsp-devel-1.2.1-1
* libspeexdsp1-1.2.1-1

Speex is a patent-free audio codec designed especially for voice
(unlike Vorbis which targets general audio) signals and providing good
narrowband and wideband quality. This project aims to be complementary to
the Vorbis codec.
-- 
  *** 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: 
.

speex 1.2.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* speex-1.2.1-1
* speex-devel-1.2.1-1
* libspeex1-1.2.1-1

Speex is a patent-free audio codec designed especially for voice
(unlike Vorbis which targets general audio) signals and providing good
narrowband and wideband quality. This project aims to be complementary to
the Vorbis codec.
-- 
  *** 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: 
.

libvorbis 1.3.7-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libvorbis-1.3.7-1
* libvorbis-devel-1.3.7-1
* libvorbis0-1.3.7-1
* libvorbisenc2-1.3.7-1
* libvorbisfile3-1.3.7-1

Ogg Vorbis is a fully open, non-proprietary, patent-and-royalty-free,
and general-purpose compressed audio format for audio and music at
fixed and variable bitrates from 16 to 128 kbps/channel.
-- 
  *** 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: 
.

libogg 1.3.4-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libogg-1.3.4-1
* libogg-devel-1.3.4-1
* libogg0-1.3.4-1

Libogg is a library for manipulating ogg bitstreams.  It handles both
making ogg bitstreams and getting packets from ogg bitstreams.
-- 
  *** 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: 
.

flac 1.4.3-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* flac-1.4.3-1
* flac-devel-1.4.3-1
* flac-docs-1.4.3-1
* libFLAC12-1.4.3-1
* libFLAC++10-1.4.3-1

FLAC is an Open Source lossless audio codec developed by Josh Coalson.
-- 
  *** 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: 
.

mpg123 1.32.6-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* mpg123-1.32.6-1
* mpg123-pulse-1.32.6-1
* libmpg123_0-1.32.6-1
* libmpg123-devel-1.32.6-1
* libout123_0-1.32.6-1
* libout123-devel-1.32.6-1

mpg123 is a cross-platform, real time MPEG 1.0/2.0/2.5 audio
player/decoder for layers 1,2 and 3 (MPEG 1.0 layer 3 aka MP3 most
commonly tested).
-- 
  *** 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: 
.

fribidi 1.0.14-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* fribidi-1.0.14-1
* libfribidi0-1.0.14-1
* libfribidi-devel-1.0.14-1
* libfribidi-doc-1.0.14-1

A library that implements the Unicode Bidirectional Algorithm
(also knows as BiDi).
-- 
  *** 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: 
.

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

opus 1.5.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libopus0-1.5.2-1
* libopus-devel-1.5.2-1
* libopus-doc-1.5.2-1

The Opus codec is designed for interactive speech and audio
transmission over the Internet. It is designed by the IETF Codec Working
Group and incorporates technology from Skype's SILK codec and Xiph.Org's
CELT codec.
-- 
  *** 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: 
.

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Takashi Yano via Cygwin-apps]

On Fri, 5 Apr 2024 13:46:18 +0100
Jon Turney wrote:
> On 02/04/2024 15:58, Takashi Yano via Cygwin-apps wrote:
> > On Tue, 2 Apr 2024 15:38:25 +0100
> > Jon Turney wrote:
> >> On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote:
> >>> On 3/30/2024 8:25 AM, Jon Turney wrote:
> >>>> On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote:
> >>>>> On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote:
> >>>> [...]
> >>>>>> David,
> >>>>>>
> >>>>>> Is it possible to update/rebuild rdiff-backup, which replies upon
> >>>>>> the soon-to-be removed python36?
> >>>>>>
> >>>>>> (Or indicate that you are no longer interested in maintaining this
> >>>>>> package, which will probably lead to it's removal).
> >>>>>
> >>>>> Please remove me as the maintainer from that package. I no longer use
> >>>>> it, and no longer have an environment for building packages for Cygwin.
> >>>>
> >>>> No problem. Thanks for maintaining it in the past.
> >>>>
> >>>> Is the same true for your other packages?
> >>>>
> >>>> $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED
> >>>> cyrus-sasl   David Rothenberger
> >>>> flac David Rothenberger
> >>>> libao    David Rothenberger
> >>>> libapr1  David Rothenberger
> >>>> libaprutil1  David Rothenberger
> >>>> libkate  David Rothenberger
> >>>> libogg   David Rothenberger
> >>>> librsync David Rothenberger
> >>>> libtheora    David Rothenberger
> >>>> libvorbis    David Rothenberger
> >>>> rdiff-backup David Rothenberger
> >>>> speex    David Rothenberger
> >>>> speexdsp David Rothenberger
> >>>> vorbis-tools David Rothenberger
> >>>> which    David Rothenberger
> >>>> whois    David Rothenberger
> >>>
> >>> Yes, I'm afraid it is.
> >>
> >> Done.  Thanks for all your work on these in the past.
> > 
> > Hi, I would like to take over the maintenance of:
> >>>> flac David Rothenberger
> >>>> libao    David Rothenberger
> >>>> libogg   David Rothenberger
> >>>> libtheora    David Rothenberger
> >>>> libvorbis    David Rothenberger
> >>>> speex    David Rothenberger
> >>>> speexdsp David Rothenberger
> >>>> vorbis-tools David Rothenberger
> > if anyone would not.
> > 
> 
> Thanks. I added these to your packages.

Thanks!

> I generated missing packaging history repos for some of these from the 
> CTM history.  Please let me know if there's any errors or if you'd like 
> those removed.
> 
> I didn't check, but if any of these are no longer carried by recent 
> linux distros, maybe think about if it's actually useful to keep on 
> having a package for it...

All these packages are required by my other packages such as ffmpeg,
timidity++, pulseaudio, etc. except for vorbis-tools.
Also, these still exist in fedora rpms repos.

-- 
Takashi Yano 

snappy 1.2.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libsnappy1-1.2.0-1
* libsnappy-devel-1.2.0-1

Snappy is a compression/decompression library. It does not aim for
maximum compression, or compatibility with any other compression library,
instead, it aims for very high speeds and reasonable compression.
-- 
  *** 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: 
.

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Takashi Yano via Cygwin-apps]

On Tue, 2 Apr 2024 15:38:25 +0100
Jon Turney wrote:
> On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote:
> > On 3/30/2024 8:25 AM, Jon Turney wrote:
> >> On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote:
> >>> On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote:
> >> [...]
>  David,
> 
>  Is it possible to update/rebuild rdiff-backup, which replies upon 
>  the soon-to-be removed python36?
> 
>  (Or indicate that you are no longer interested in maintaining this 
>  package, which will probably lead to it's removal).
> >>>
> >>> Please remove me as the maintainer from that package. I no longer use 
> >>> it, and no longer have an environment for building packages for Cygwin.
> >>
> >> No problem. Thanks for maintaining it in the past.
> >>
> >> Is the same true for your other packages?
> >>
> >> $ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED
> >> cyrus-sasl   David Rothenberger
> >> flac David Rothenberger
> >> libao    David Rothenberger
> >> libapr1  David Rothenberger
> >> libaprutil1  David Rothenberger
> >> libkate  David Rothenberger
> >> libogg   David Rothenberger
> >> librsync David Rothenberger
> >> libtheora    David Rothenberger
> >> libvorbis    David Rothenberger
> >> rdiff-backup David Rothenberger
> >> speex    David Rothenberger
> >> speexdsp David Rothenberger
> >> vorbis-tools David Rothenberger
> >> which    David Rothenberger
> >> whois    David Rothenberger
> > 
> > Yes, I'm afraid it is.
> 
> Done.  Thanks for all your work on these in the past.

Hi, I would like to take over the maintenance of:
> >> flac David Rothenberger
> >> libao    David Rothenberger
> >> libogg   David Rothenberger
> >> libtheora    David Rothenberger
> >> libvorbis    David Rothenberger
> >> speex    David Rothenberger
> >> speexdsp David Rothenberger
> >> vorbis-tools David Rothenberger
if anyone would not.

Thanks in advance.

-- 
Takashi Yano 

SDL2 2.30.2-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libSDL2_2.0_0-2.30.2-1
* libSDL2-devel-2.30.2-1

This is the Simple DirectMedia Layer, a general API that provides
low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL,
and 2D framebuffer across multiple platforms.
-- 
  *** 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: 
.

nv-codec-headers 12.2.72.0-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* nv-codec-headers-12.2.72.0-1

FFmpeg version of headers required to interface with Nvidias codec APIs. This 
package provides headers which loads corresponding dlls dynamically. The codec 
itself is implemented in the dlls and the Nvidia GPU.
-- 
  *** 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: 
.

opus 1.5.1-1

[Takashi Yano via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* libopus0-1.5.1-1
* libopus-devel-1.5.1-1
* libopus-doc-1.5.1-1

The Opus codec is designed for interactive speech and audio
transmission over the Internet. It is designed by the IETF Codec Working
Group and incorporates technology from Skype's SILK codec and Xiph.Org's
CELT codec.
-- 
  *** 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: 
.

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, );
> >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, );
>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