wmemset() regression with 3.4.2

The following example works with 3.3.6, but fails with 3.4.2. It's a reduced example from pacman which started to produce garbage output in some places after upgrading to 3.4.2. While I noticed it in MSYS2 first, I have confirmed it with 3.3.6 and 3.4.2 in cygwin. ``` #include #include #include

Re: wmemset() regression with 3.4.2

I can confirm that reverting the asm change in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=188d5f6c9ad5cbbd6f0fcb9aaf15bc9870597910 seems to make things work again. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Fork issues with 3.4 in Docker only

After the upgrade to 3.4 (disclaimer: in MSYS2) I'm seeing, and getting reports of, various things failing in Docker only, for example: 1 [main] pacman 252 child_copy: dll data read copy failed, 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 5096, Win32 error 299 0 [main] pacman 2

cygwin + binutils 2.36 + ASLR/dynamicbase defaults

Hey, binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled linker will give you: > peflags -v mydll.dll mydll.dll: coff(0x2026[+executable_image,+line_nums_stripped,+bigaddr,+dll]) pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) Is this still problematic for cygwin? The re

Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults

On Sun, Feb 28, 2021 at 1:16 PM ASSI wrote: > > Christoph Reiter via Cygwin writes: > > binutils 2.36 now defaults to ASLR etc on Windows, so a cygwin compiled > > linker > > will give you: > > > >> peflags -v mydll.dll > > mydll.dll: coff(0x2026[+

Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults

On Sun, Feb 28, 2021 at 3:22 PM ASSI wrote: > > Christoph Reiter via Cygwin writes: > > MSYS2 builds all packages with ASLR since 6 months, so things look > > good. > > That doesn't tell you all that much since you will have to wait for some > unfavorable addre

Re: Would it be possible to update the bash package?

On Fri, Mar 5, 2021 at 5:50 PM L A Walsh wrote: > Really I don't see a compelling reason there should be > any hurry to update. In my own testing, I've been unable to > build a version that doesn't crash/dump core on linux and don't > really think the 5.x series has had a thorough vetting

stdin pipe rename in 3.2.0

Hey, I noticed that the stdin pipe was renamed from "\msys-dd50a72ab4668b33-pty1-from-master" to "\msys-dd50a72ab4668b33-pty0-to-slave" in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=bb42852062073439 This trips up https://github.com/k-takata/ptycheck to detect the cygpty which is used

Re: stdin pipe rename in 3.2.0

On Fri, Mar 19, 2021 at 4:47 AM Brian Inglis wrote: > > On 2021-03-18 14:28, Christoph Reiter via Cygwin wrote: > If these are being renamed should they not now use neutral terminology based > on > terms such as primary and secondary, and the primary/default repo branches on >

Re: stdin pipe rename in 3.2.0

On Fri, Mar 19, 2021 at 11:09 AM Takashi Yano via Cygwin wrote: > > On Thu, 18 Mar 2021 21:28:40 +0100 > Christoph Reiter wrote: > > I noticed that the stdin pipe was renamed from > > > > "\msys-dd50a72ab4668b33-pty1-from-master" to > > "\msys-dd50a72ab4668b33-pty0-to-slave" in > > https://cygwin.