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
int main()
{
char dest[50] = { 0 };
wchar_t src[] = L"example";
wmemset(src, L'E', 1);
if (wcstombs(dest, src, 7) == -1) {
printf("FAILED\n");
return 1;
}
printf("OK: %s\n", dest);
return 0;
}
```
thanks
--
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: 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:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
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 251 dofork: child -1 - forked process 5096 died unexpectedly, retry 0, exit code 0xC005, errno 11 0 [main] pacman 253 child_copy: dll data read copy failed, 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 584, Win32 error 299 67887 [main] pacman 251 dofork: child -1 - forked process 584 died unexpectedly, retry 0, exit code 0xC005, errno 11 0 [main] pacman 254 child_copy: dll data read copy failed, 0x7FF8C816C000..0x7FF8C8178EB0, done 0, windows pid 2336, Win32 error 299 124719 [main] pacman 251 dofork: child -1 - forked process 2336 died unexpectedly, retry 0, exit code 0xC005, errno 11 Reverting https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=943433b00cacdde0cb9507d0178770a2fb67bd71 fixes things again. Note that this doesn't happen outside of Docker, I've built more than 100 packages with 3.4 on different hosts without any issues, and the errors in Docker are pretty consistent, so I'm guessing that something with ASLR behaves differently under Docker(?) Note that I haven't had time to look into reproducing it with cygwin itself. I can try to do that if needed. thanks -- 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
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 reason I'm asking is because we updated to 2.36 in MSYS2 and are wondering if we need to patch this out (or change the defaults) It seems to work as is right now, but maybe we are just lucky(?). Some context: https://github.com/msys2/MSYS2-packages/pull/2345 regards -- 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 + 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[+executable_image,+line_nums_stripped,+bigaddr,+dll]) > > pe(0x0160[+high-entropy-va,+dynamicbase,+nxcompat]) > > > > Is this still problematic for cygwin? > > Yes it is and I'm currently figuring out how to best get rid of it in > order to be able to update binutils (why this was ever allowed in > without an accompanying configure option is a mystery to me). OK, thanks (nxcompat as well btw?). I've reverted these changes in MSYS2 now: https://github.com/msys2/MSYS2-packages/commit/c5757a43b42fb20730792469facf9a65571a2e81 > I've > already nixed it for Cygwin, but I'm not yet sure what to do for the > cross compilation toolchain. While it should in principle work there, > I'm pretty sure that there will be problems when it comes to the nitty > gritty details. It's already transpired that some of the linker scripts > can't deal with the larger base addresses this change does generate > eventually. MSYS2 builds all packages with ASLR since 6 months, so things look good. We've added a patch that allows reverting the base address if needed: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-binutils/2001-ld-option-to-move-default-bases-under-4GB.patch > > The reason I'm asking is because we updated to 2.36 in MSYS2 and are > > wondering if we need to patch this out (or change the defaults) It > > seems to work as is right now, but maybe we are just lucky(?). > > You are just lucky and need to test more. :-) > > Note that the change does not only affect DLL as the commit message > would want you to believe and you will eventually end up with a > situation where ASLR tries moves the stack of an executable, at which > point you can no longer fork. OK, thanks. -- 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 + 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 address space layout constellation to appear for the problem > to announce itself and then you need someone to recognize the reason and > report it back to you. I tend to see this only on 32bit on my > development machine where I have a large amount of dependencies > installed. After a reboot the problem will move somewhere else, which > means that you will need to find another reproducer. To clarify: I was referring to non-cygwin targets. I had assumed you meant that by "cross compilation toolchain". > > We've added a patch that allows reverting the base address if needed: > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-binutils/2001-ld-option-to-move-default-bases-under-4GB.patch > > In other words, that should be the default then since you can't know if > it works otherwise. Also, I really don't think we should need to change > all toolchains to use these options just in order to produce working > executables. If "safer" means "it doesn't work", then there are clearly > easier ways to get there. We've only needed this to to work around linker errors, so it's pretty clear when it is needed as the build will fail. Anyway, maybe the linked patches can be helpful to you. regards -- 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: 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 such > that it would be regarded as being as stable as 4.3/4.4. fyi, we've been using bash 5.1 in MSYS2 for 2-3 months now without any issues. regards -- 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
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 in various code bases. Is there a reason it was renamed? And while grepping I noticed the old name is still checked for in other places like https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/tty.cc;h=3c016315cdedb1dcca44cb3f3f96b87fd0b90a97;hb=HEAD#l162 which seems weird. Thanks! -- 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: 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 > a > term such as main? Yes. Though there are ~700 instances of such terms in the cygwin code so I'd suggest you propose this separately to the list. Thanks! -- 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: 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.com/git/?p=newlib-cygwin.git;a=commit;h=bb42852062073439 > > Actually, this is not renamed but newly introduced only > for non-cygwin (native) apps. ah, I see. > > This trips up https://github.com/k-takata/ptycheck to detect the > > cygpty which is used in various code bases. > > If this change is affected, your process seems to be > a non-cygwin process. yes, I noticed this with non-cygwin processes. > > Is there a reason it was renamed? > > > > And while grepping I noticed the old name is still checked for in > > other places like > > https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/tty.cc;h=3c016315cdedb1dcca44cb3f3f96b87fd0b90a97;hb=HEAD#l162 > > which seems weird. > > The name "from-master" is still used for cygwin > processes. ok. > However, the naming was not appropriate. > The name of output pipes are: > "pty-to-master-cyg" for cygwin process, > and > "pty-to-master" for non-cygwin process. > > However, the name of input pipes are: > "pty-from-master" for cygwin process, > and > "pty-to-slave" for non-cygwin process. > This is not only consistent but also very confusing. > > I would like to rename these pipes to: > "pty-from-master-cyg" for cygwin process, > "pty-from-master" for non-cygwin process. If the naming was changed to keep https://github.com/k-takata/ptycheck working then it would help me a lot. But I also don't mind patching this on our side. Thanks! -- 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
Crashes in cmake subprocesses since 3.6.0
Starting with 3.6.0 when cmake calls into make/ninja/gcc there is a chance of
that failing, for example like this:
CMake Error: Generator: build tool execution failed, command was:
/usr/bin/cmake.exe -E env VERBOSE=1 /usr/bin/make.exe -f Makefile
cmTC_c87e2/fast
* Problem starts with cygwin 3.6.0
* Problem starts with cmake 3.29+ (3.31 is in Cygwin marked as test
and is new enough)
* It doesn't seem to matter which tool is called from cmake
* Downgrading either cmake to 3.28 or cygwin to 3.5.7 makes the problem go away
Instructions for how to reproduce in Cygwin:
* Update Cygwin install to have 3.6.0
* Install the testing version (3.31.3 atm) of cmake
* Run mintty (for some reason in the Windows Terminal it doesn't
reproduce for me)
```
# CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(MinimalChecks C)
include(CheckCSourceCompiles)
foreach(i RANGE 1 100)
check_c_source_compiles("int main() { return 0;}" CHECK_${i})
endforeach()
```
```
cmake -B _build --fresh
# also fails: cmake -B _build --fresh -DCMAKE_MAKE_PROGRAM="echo"
```
Expected: 100 times "Success"
Actual: sometimes "Failed"
Related downstream issue with a bit more context/history:
https://github.com/msys2/msys2-runtime/issues/272#issuecomment-2764714256
--
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
Problems with flushing stdin in mintty
I'm having the problem that under cygwin flushing stdin for some reason doesn't
work when running in mintty. It works when running cygwin in the Windows
terminal though. In my case the program using this is pacman, where it asks
various questions and if you hit some keys in-between questions they leak into
the next one, resulting in invalid input.
Example program showing the problem. Type some text in the first 5 seconds, and
see the input leak into the next input. Any ideas/workarounds welcome.
```c
// gcc -o flush_stdin flush_stdin.c
#include
#include
#include
int main() {
printf("type something in the next 5 secs\n");
for (int i=0; i < 5; i++) {
sleep(1);
printf("%d\n", i);
}
// Flush stdin
int fd = fileno(stdin);
if (fd != -1) {
printf("flushing stdin\n");
if (tcflush(fd, TCIFLUSH) == -1) { // this doesn't seem to do anything
perror("Error flushing stdin");
return 1;
}
} else {
perror("Error getting file descriptor for stdin");
return 1;
}
char buffer[100];
printf("Enter some text:\n");
fgets(buffer, sizeof(buffer), stdin);
printf("You entered: %s\n", buffer);
return 0;
}
```
--
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
