Msys2-packages: mintty doesn't start under wine-staging

[KrullBorg]

i'm sorry, but i didn't want to open an issue about that; i just wanted to open a discussion under sourceforge but i saw that it is no longer possibile

so the problem is as the object: mintty doesn't start anymore under wine-staging after latest msys2 core updates; before updates it started but only with winxp compatibility setted

what could be the problem? thanks in advace

Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x610a569d).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:610a569d ESP:0064ca40 EBP:00000000 EFLAGS:00210257( R- -- I Z-A-P-C)
EAX:00000000 EBX:612e99e4 ECX:00000001 EDX:00000001
ESI:7ffdf000 EDI:7bc3edf0
Stack dump:
0x0064ca40: 7bc218c0 00000057 00000020 7bc7abb3
0x0064ca50: 612eafb0 00220290 00000014 6100358e
0x0064ca60: 00000007 00220000 00000001 00000001
0x0064ca70: 00000000 612e9748 612ea9a8 612e99e4
0x0064ca80: 612eafc2 00000000 0064cb18 610a5af3
0x0064ca90: 612e99e4 00000001 00000000 0064cae0
Backtrace:
=>0 0x610a569d in msys-2.0 (+0xa569d) (0x00000000)
1 0x610a5af3 in msys-2.0 (+0xa5af2) (0x0064cb18)
2 0x610a6116 in msys-2.0 (+0xa6115) (0x0064cbd8)
3 0x61006c33 in msys-2.0 (+0x6c32) (0x0064cbd8)
4 0x61005852 in msys-2.0 (+0x5851) (0x00000000)
5 0x61005914 in msys-2.0 (+0x5913) (0x0064fe40)
6 0x610069cf in msys-2.0 (+0x69ce) (0x0064fe40)
7 0x00424740 in mintty (+0x2473f) (0x0064fe40)
8 0x7b466142 call_process_entry+0x11() in kernel32 (0x0064fe58)
9 0x7b467729 in kernel32 (+0x57728) (0x0064fea8)
10 0x7bc8697c call_thread_func_wrapper+0xb() in ntdll (0x0064fed8)
11 0x7bc89bed call_thread_func+0x7c() in ntdll (0x0064ffa8)
12 0x7bc8695a RtlRaiseException+0x21() in ntdll (0x0064ffc8)
13 0x7bc5895f in ntdll (+0x4895e) (0x0064ffe8)
14 0xf75dc41d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
15 0xf75dc4db wine_switch_to_stack+0x2a() in libwine.so.1 (0xff99c438)
16 0x7bc5db2c LdrInitializeThunk+0x29b() in ntdll (0xff99c498)
17 0x7b46e198 __wine_kernel_init+0x987() in kernel32 (0xff99d3b8)
18 0x7bc5e09b __wine_process_init+0x18a() in ntdll (0xff99d448)
19 0xf75da80a wine_init+0x299() in libwine.so.1 (0xff99d4a8)
20 0x7c000bbb main+0x7a() in (0xff99d8f8)
21 0xf7406276 __libc_start_main+0xf5() in libc.so.6 (0x00000000)
0x610a569d: movzbl 0x1(%eax),%ecx
Modules:
Module Address Debug info Name (99 modules)
PE 400000- 44e000 Export mintty
PE 61000000-614f0000 Dwarf msys-2.0
ELF 7b400000-7b7ec000 Dwarf kernel32
-PE 7b410000-7b7ec000 \ kernel32
ELF 7bc00000-7bcfc000 Dwarf ntdll
-PE 7bc10000-7bcfc000 \ ntdll
ELF 7c000000-7c004000 Dwarf
ELF 7d58d000-7d5a3000 Deferred libgpg-error.so.0
ELF 7d5a3000-7d61c000 Deferred libpcre.so.3
ELF 7d61c000-7d63a000 Deferred libgcc_s.so.1
ELF 7d63a000-7d708000 Deferred libgcrypt.so.20
ELF 7d708000-7d731000 Deferred liblzma.so.5
ELF 7d731000-7d73a000 Deferred librt.so.1
ELF 7d73a000-7d765000 Deferred libselinux.so.1
ELF 7d765000-7d7f6000 Deferred libsystemd.so.0
ELF 7d7f6000-7d7ff000 Deferred libffi.so.6
ELF 7d7ff000-7d85b000 Deferred libdbus-1.so.3
ELF 7d85b000-7d8e9000 Deferred libgmp.so.10
ELF 7d8e9000-7d91f000 Deferred libhogweed.so.4
ELF 7d91f000-7d95c000 Deferred libnettle.so.6
ELF 7d95c000-7d971000 Deferred libtasn1.so.6
ELF 7d971000-7d9a5000 Deferred libidn.so.11
ELF 7d9a5000-7da06000 Deferred libp11-kit.so.0
ELF 7da06000-7da1e000 Deferred libresolv.so.2
ELF 7da1e000-7da23000 Deferred libkeyutils.so.1
ELF 7da23000-7da30000 Deferred libkrb5support.so.0
ELF 7da30000-7da35000 Deferred libcom_err.so.2
ELF 7da35000-7da68000 Deferred libk5crypto.so.3
ELF 7da68000-7db42000 Deferred libkrb5.so.3
ELF 7db42000-7db56000 Deferred libavahi-client.so.3
ELF 7db56000-7db65000 Deferred libavahi-common.so.3
ELF 7db65000-7dcf1000 Deferred libgnutls.so.30
ELF 7dcf1000-7dd44000 Deferred libgssapi_krb5.so.2
ELF 7dd44000-7ddcd000 Deferred libcups.so.2
ELF 7ddcd000-7de06000 Deferred uxtheme
-PE 7ddd0000-7de06000 \ uxtheme
ELF 7de06000-7de0d000 Deferred libxfixes.so.3
ELF 7de0d000-7de19000 Deferred libxcursor.so.1
ELF 7de27000-7de51000 Deferred libexpat.so.1
ELF 7de51000-7de94000 Deferred libfontconfig.so.1
ELF 7de94000-7dece000 Deferred libpng16.so.16
ELF 7dece000-7deeb000 Deferred libz.so.1
ELF 7deeb000-7df9f000 Deferred libfreetype.so.6
ELF 7df9f000-7dfb2000 Deferred libxi.so.6
ELF 7dfb2000-7dfb6000 Deferred libxcomposite.so.1
ELF 7dfb6000-7dfc3000 Deferred libxrandr.so.2
ELF 7dfc3000-7dfcf000 Deferred libxrender.so.1
ELF 7dfcf000-7dfd6000 Deferred libxxf86vm.so.1
ELF 7dfd6000-7dfda000 Deferred libxinerama.so.1
ELF 7dfda000-7e000000 Deferred libxcb.so.1
ELF 7e000000-7e152000 Deferred libx11.so.6
ELF 7e152000-7e167000 Deferred libxext.so.6
ELF 7e175000-7e20c000 Deferred winex11
-PE 7e180000-7e20c000 \ winex11
ELF 7e20c000-7e2c7000 Deferred winmm
-PE 7e210000-7e2c7000 \ winmm
ELF 7e2c7000-7e34d000 Deferred rpcrt4
-PE 7e2d0000-7e34d000 \ rpcrt4
ELF 7e34d000-7e494000 Deferred ole32
-PE 7e360000-7e494000 \ ole32
ELF 7e494000-7e4ba000 Deferred imm32
-PE 7e4a0000-7e4ba000 \ imm32
ELF 7e4ba000-7e4fd000 Deferred winspool
-PE 7e4c0000-7e4fd000 \ winspool
ELF 7e4fd000-7e578000 Deferred shlwapi
-PE 7e510000-7e578000 \ shlwapi
ELF 7e578000-7e845000 Deferred shell32
-PE 7e590000-7e845000 \ shell32
ELF 7e845000-7e936000 Deferred comdlg32
-PE 7e850000-7e936000 \ comdlg32
ELF 7e936000-7e950000 Deferred version
-PE 7e940000-7e950000 \ version
ELF 7e950000-7e9cc000 Deferred advapi32
-PE 7e960000-7e9cc000 \ advapi32
ELF 7e9cc000-7eb02000 Deferred gdi32
-PE 7e9e0000-7eb02000 \ gdi32
ELF 7eb02000-7ec63000 Deferred user32
-PE 7eb10000-7ec63000 \ user32
ELF 7ec63000-7ed6f000 Deferred comctl32
-PE 7ec70000-7ed6f000 \ comctl32
ELF 7ed91000-7eda4000 Deferred libnss_files.so.2
ELF 7eda4000-7edb1000 Deferred libnss_nis.so.2
ELF 7edb1000-7edcc000 Deferred libnsl.so.1
ELF 7edcc000-7edd5000 Deferred libnss_compat.so.2
ELF 7efab000-7f000000 Deferred libm.so.6
ELF f734a000-f7386000 Deferred ws2_32
-PE f7350000-f7386000 \ ws2_32
ELF f7386000-f73b0000 Deferred iphlpapi
-PE f7390000-f73b0000 \ iphlpapi
ELF f73b0000-f73e0000 Deferred netapi32
-PE f73c0000-f73e0000 \ netapi32
ELF f73e0000-f73e7000 Deferred libxdmcp.so.6
ELF f73e9000-f73ee000 Deferred libdl.so.2
ELF f73ee000-f75a5000 Dwarf libc.so.6
ELF f75a5000-f75c2000 Deferred libpthread.so.0
ELF f75c5000-f75c9000 Deferred libxau.so.6
ELF f75d0000-f779c000 Dwarf libwine.so.1
ELF f779f000-f77c4000 Deferred ld-linux.so.2
ELF f77c6000-f77c7000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
0000000e services.exe
00000022 0
00000021 0
00000019 0
00000018 0
00000016 0
00000012 0
0000000f 0
00000010 explorer.exe
00000029 0
00000028 0
00000027 0
00000011 0
00000014 winedevice.exe
00000020 0
0000001d 0
0000001c 0
0000001b 0
0000001a 0
00000015 0
0000001e plugplay.exe
00000024 0
00000023 0
0000001f 0
00000025 (D) C:\msys32\usr\bin\mintty.exe
0000002a 2
00000026 0 <==
System information:
Wine build: wine-1.9.18 (Staging)
Platform: i386 (WOW64)
Version: Windows XP
Host system: Linux
Host version: 4.7.0-1-amd64

[mati865]

You could try compiling mintty 2.6.0 with new runtime version.
Another way to use MSYS2 inside Linux: https://github.com/Krakonos/msysww.

[KrullBorg]

how if mintty doesn't start? i also tried "wineconsole --backend=curses usr/bin/bash -l"

[mati865]

Run it from Linux console.

msysww --init
msysww -c

[KrullBorg]

if i understood "msysww -c" runs what i already tried (https://github.com/Krakonos/msysww/blob/master/msysww#L153); right?

[mati865]

-c runs default console (MSYS2).
Works nice for me on Arch with exception of 2 or 3 Wine bugs.

[KrullBorg]

but it runs the command https://github.com/Krakonos/msysww/blob/master/msysww#L153 or i didn't understand it? in the first case, as you can see on comment before, i already tried that command and it crashes

[fracting]

@KrullKorg what's your wine version? what's your msys2 runtime version?

Is it possible a Msys2 version later than or equal to 2.6.0?

corinna, would you be surprised if cygwin crashing on wine starts from this commit: ffcef702e78f81c64376dbe7547f242f67b433d4
Drop has_fast_cwd flag
crashing immediately at start
my bisect seems show that commit if i done it correctly
fracting, I wouldn't be surprised
unless you provide the new fast cwd method as Vista and laer
later
the old method up to XP/2K3 is not available anymore

[fracting]

Also take care about https://bugs.wine-staging.com/show_bug.cgi?id=682

[KrullBorg]

debian gnu/linux sid updated to last version (an lxc container inside debian gnu/linux sid updated to latest version)
libfreetype6 2.6.3-3+b1
wine-staging 1.9.18~sid
msys2 i don't know because mintty doesn't start, but i think it is the latest version

[fracting]

@KrullKorg

I think it is exact the problem I was discuss with corrina on irc. The latest msys2-runtime version is 2.6.0 after core-update, according to repo.msys2.org: http://repo.msys2.org/msys/i686/msys2-runtime-2.6.0-1-i686.pkg.tar.xz

The only way to workaround is, manually download old msys2-runtime version and manually revert /usr/bin/msys-2.0.dll

if it's hard to get Msys2 right on Wine for you, you can try https://hub.docker.com/r/teaci/msys64/ and https://hub.docker.com/r/teaci/msys32/ as the last chance, which are used by tea-ci.org
You can also try mirrors.tea-ci.org/msys2, which is used by Tea CI, maintain an outdated Msys2 mirror version, but keep compatibility with Wine.

Sorry I don't have time to continue join corrina to fix this soon until few months later, any one could give a hand would be great helpful...

`

[fracting]

<corinna>      the old method up to XP/2K3 is not available anymore
<fracting>     corinna, thanks, that explains. do you have a quick msdn link for vista fast cwd?
<corinna>      there is none
<corinna>      this is strictly internal to ntdll.dll
<corinna>      the onlydocs for that are inside Cygwin
<corinna>      the source code has lots of comments how this works
<corinna>      path.cc in the first place
<fracting>     ah, ok, nice
<corinna>      uh oh
<corinna>      that will be almost impossible to emulate
<fracting>     really? :/
<corinna>      take a very deep breath and have a look at find_fast_cwd_pointer()
<corinna>      but
<corinna>      hang on
<corinna>      that would mean Cygwin never worked in Vista emulation mode?
<corinna>      how do you run Cygwin in wine?
<fracting>     always XP mode in the past
<corinna>      in what OS emulation mode
<corinna>      that's the problem
<corinna>      so you never noticed this before
<corinna>      you really should run this in the latest emulation mode available
<corinna>      we can get it to work but it requires wine to provide a matching FAST_CWD struct based on the OS emulation mode

<jturney1>     shouldn't the cygwin DLL be marked with a minimum os version so it won't load on XP?
<corinna>      hmm, that will be tricky
<corinna>      jturney1, it uses entry points not available on XP now
<jturney1>     yeah
<corinna>      this isn't the problem
<jturney1>     but doesn't it get you a better error message?
<corinna>      the problem is that up to 2.5.1 it *did* run on XP so it has been tested in XP mode
<corinna>      but it would have never worked correctly in Vista or later emulation
<corinna>      but this has gone unnoticed
<corinna>      you know, this will be tricky to implement
<corinna>      it's an undocumented pointer to an undomcumented datastructure in ntdll.dll
<fracting>     very interesting
<corinna>      which even changed twice over the time
<corinna>      and Cygwin scans the code to find the pointer inside ntdll.dll
<corinna>      but there's practically no chance that you can generate the same assembler code as Visual C++
<fracting>     so even cygwin was harmed by the undocumented data structure?
<corinna>      yes
<fracting>     is that find_fast_cwd_pointer for performance improving, or no other way to implement at all?
<corinna>      we could have just given up and removed some POSIX features, but we didn't want to
<fracting>     what POSIX feature does it map to?
<corinna>      keep in mind that this is undocumented so the name FAST_CWD is an invention of the guy on the CYgwin ML  who tracked it down
<fracting>     ;)
<corinna>      it *seems* the idea of this change was to avoid potential crahes with multiple threads using and manipulating the CWD
<corinna>      while avoiding a global lock on the CWD
<corinna>      so what they did instead
<corinna>      Set/GetCurrentDirectory now don't use the CWD stored in PEB::ProcessParameters anymore

<corinna>      instead there's a new structure
<corinna>      what we call FAST_CWD
<corinna>      and a global (undocumented) pointer to the current FAST_CWD struct
<fracting>     very interesting XD
<corinna>      RtlGetCurrentDirectory_U fetches the current FAST_CWD pointer from the global pointer, incremens a use count
<corinna>      and reads the value
<fracting>     i need a deep breath as you said :)
<corinna>      RtlSetCurrentDirectory_U allocates a new FAST_CWD struct, fills it with life, and moves the global pointer to the new struct
<corinna>      then it checks if the use count of the old struct is 0, and, if so, deallocates it
<corinna>      the latter is also done by RtlGetCurrentDirectory_U, so the strcut disappears as soon as it has no user
<corinna>      Before we discuss this further
<fracting>     https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L953
<corinna>      I would like to ask you to read the (really extensive) comments in path.cc, starting at line 3814
<fracting>     current wine emulates older windows like xp, right?
<corinna>      yup, that's the old technique
<corinna>      also, have a look at the strcut itself
<corinna>      grr
<corinna>      *struct*
<corinna>      it's defined in cygheap.h starting at line 204
<corinna>      I made sure to have lots and lots of comments
<corinna>      because it's the *only* documentation available
<fracting>     corinna, re L3814, you mean take care of copyright?
<corinna>      no
<corinna>      it's just the start of the code
<corinna>      yeah. it's the copyright comment
<corinna>      it's just the natural start for reading the code handling the CWD
<corinna>      just skip the copyright header
<fracting>     you mean start from fcwd_access_t::SetFSCharacteristics ?
<corinna>      never mind, maybe first have a look into cygheap.h to see how the struct looks like
<fracting>     yeah,
<fracting>     04 enum fcwd_version_t {
<fracting>     205   FCWD_OLD,
<fracting>     206   FCWD_W7,
<fracting>     207   FCWD_W8
<fracting>     208 };
<corinna>      as for the source in path.cc, it might be better to make sure you have tags and then start at cwdstuff::set and jump to the called functions to see what's going on
<fracting>     and more
<corinna>      I'm assuming you checkout out the sources with git and use an editor like vim or emacs
<jturney1>     or ed
<jturney1>     :)
<corinna>      right
<corinna>      not everybody wants to use these fancy editors
<fracting>     vim :)
<corinna>      good
<corinna>      read the comments
<corinna>      class fcwd_access_t is pretty easy to understand I hope
<fracting>     yep
<corinna>      *probably* we could remove the FAST_CWD_OLD type now, too
<corinna>      but
<corinna>      if somebody actually re-installs Vista or W7 from scratch, Cygwin would be broken as long as KB 2393802 hasn't been installed
<corinna>      so I rather keep it in for now

<fracting>     i see
<corinna>      fortunately there wasno change since W8
<Stromeko>     Don't tell M$, they change it if you ask nicely enough.
<corinna>      yuk
<corinna>      I dread every new OS version becasue of this code
<Stromeko>     ALso, if they do, it will be fun since all changes will be named W10. ;-)
<corinna>      haha
<corinna>      yselkowitz1, ping?
<fracting>     corinna, i feel that mircosoft makes your life very hard :)

<corinna>      fracting, I think we need some way to recognize running under wine from inside Cygwin
<corinna>      or
<corinna>      here's another idea
<corinna>      ok
<corinna>      I have an idea how to solve this...
<corinna>      but we cqan discuss this later
<fracting>     (example of detect wine: GetProcAddress("wine_get_version") https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/ntdll.spec#L1463 )
<corinna>      fracting, on second thought, there might be a better way
<fracting>     yes?:)
<corinna>      first, reimplement the new RtlGet/SetCurrentDirectory_U
<corinna>      it's not too tricky
<corinna>      second, export the global pointer pointing to this struct
<corinna>      e.g. a wine-specific function which returns the pointer
<corinna>      Cygwin could then call  GetProcAddress("wine_get_fast_cwd_ptr_func") and if that worked, just skip find_fast_cwd_pointer
<fracting>     i like this idea, but i believe this kinds of wine_get_fast_cwd_ptr_func wouldn't be accepted by wine upstream. however, in the worst case, i don't mind maintain a custom fork of wine with this extension, since i don't have any better idea as well
<corinna>      uhm
<corinna>      hmm
<corinna>      just looing into https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L987
<corinna>      s/looing/looking/
<corinna>      is that identical to upstream?
<fracting>     it's the same version i'm using daily
<fracting>     since wine staging was accepted as part of official wine version, so it could be called as upstream as well. if you mean a traditional winehq version, let me check a while
<corinna>      I just wonder how the handle is treated
<fracting>     winehq version seems the same: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/path.c#l987
<corinna>      oh, hang on
<corinna>      the sharing flags are 0
<corinna>      so that's as in real windows
<corinna>      hmm
<corinna>      let me think about this for a bit, but we may end up reverting ffcef70 and use the old XP code in case we know we'er running on wine instead

<corinna>      hmm
<corinna>      just looing into https://github.com/wine-compholio/wine-patched/blob/master/dlls/ntdll/path.c#L987
<corinna>      s/looing/looking/
<corinna>      is that identical to upstream?
<fracting>     it's the same version i'm using daily
<fracting>     since wine staging was accepted as part of official wine version, so it could be called as upstream as well. if you mean a traditional winehq version, let me check a while
<corinna>      I just wonder how the handle is treated
<fracting>     winehq version seems the same: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/path.c#l987
<corinna>      oh, hang on
<corinna>      the sharing flags are 0
<corinna>      so that's as in real windows
<corinna>      hmm
<corinna>      let me think about this for a bit, but we may end up reverting ffcef70 and use the old XP code in case we know we'er running on wine instead
<yselkowitz>   is other xp code going to have to be reverted for wine too? :-S
<corinna>      no
<fracting>     re ffcef70, that seems also a good idea

[KrullBorg]

yes i downgraded msys2-runtime and mintty and it works

[andreygursky]

The same issue (wine-staging 1.9.18). Replacing msys-2.0.dll (from msys2-runtime-2.6.0-1-i686.pkg.tar.xz) with one from msys2-runtime-2.5.2-2-i686.pkg.tar.xz and mintty.exe (from mintty-1~2.5.0-1-i686.pkg.tar.xz) with one from mintty-1~2.4.2-1-i686.pkg.tar.xz workarounds the issue at the moment.

Despite of presence of msys-2.0.dbg, there is no source line info:

[...]
trace:dbghelp:SymMatchFileNameW (L"c:\\msys32\\usr\\bin\\msys-2.0.dbg" L"" (nil) (nil))
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dbg", but wrong timestamp
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dbg", but wrong size
trace:dbghelp:SymMatchFileNameW (L"c:\\msys32\\usr\\bin\\msys-2.0.dll" L"" (nil) (nil))
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dll", but wrong timestamp
warn:dbghelp:module_find_cb Found L"c:\\msys32\\usr\\bin\\msys-2.0.dll", but wrong size
[...]
fixme:advapi:LsaOpenPolicy ((null),0x6129dbe0,0x00000001,0x64c304) stub
fixme:advapi:LsaClose (0xcafe) stub
fixme:netapi32:NetUserGetInfo Level 3 is not implemented
Unhandled exception: page fault on read access to 0x00000001 in 32-bit code (0x610a569d).
err:dbghelp:pe_load_msc_debug_info -Debug info stripped, but no .DBG file in module L"mintty"
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:610a569d ESP:0064ca30 EBP:00000000 EFLAGS:00210257(  R- --  I  Z-A-P-C)
 EAX:00000000 EBX:612e99e4 ECX:00000001 EDX:00000001
 ESI:7ffdf000 EDI:7bc3dc00
Stack dump:
0x0064ca30:  7bc22000 00000057 00000020 00000000
0x0064ca40:  00000007 00000030 00220024 00000026
0x0064ca50:  00000000 00220000 00000001 00000001
0x0064ca60:  00220024 00000000 0064cb08 612e99e4
0x0064ca70:  612eafc4 00000000 0064cb08 610a5af3
0x0064ca80:  612e99e4 00000001 00000000 0064cad0
Backtrace:
=>0 0x610a569d in msys-2.0 (+0xa569d) (0x00000000)
  1 0x610a5af3 in msys-2.0 (+0xa5af2) (0x0064cb08)
  2 0x610a6116 in msys-2.0 (+0xa6115) (0x0064cbc8)
  3 0x61006c33 in msys-2.0 (+0x6c32) (0x0064cbc8)
  4 0x61005852 in msys-2.0 (+0x5851) (0x00000000)
  5 0x61005914 in msys-2.0 (+0x5913) (0x0064fe30)
  6 0x610069cf in msys-2.0 (+0x69ce) (0x0064fe30)
  7 0x00424740 in mintty (+0x2473f) (0x0064fe30)
  8 0x7b45f582 call_process_entry+0x11() in kernel32 (0x0064fe48)
  9 0x7b460768 start_process+0x87(entry=<couldn't compute location>) [/build/source/dlls/kernel32/process.c:1122] in kernel32 (0x0064fe88)
  10 0x7bc7f87c call_thread_func_wrapper+0xb() in ntdll (0x0064feb8)
  11 0x7bc82681 call_thread_func+0xb0(entry=0x7b4606e0, arg=0x401000, frame=0x64ffb8) [/build/source/dlls/ntdll/signal_i386.c:2815] in ntdll (0x0064ff98)
  12 0x7bc7f85a RtlRaiseException+0x21() in ntdll (0x0064ffb8)
  13 0x7bc55706 start_process+0x35(kernel_start=0x7b4606e0) [/build/source/dlls/ntdll/loader.c:3430] in ntdll (0x0064ffe8)
  14 0xf75e337d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000)
  15 0xf75e34e0 wine_switch_to_stack+0x1f(func=0x7bc556d0, arg=0x7b4606e0, stack=0x650000) [/build/source/libs/wine/port.c:77] in libwine.so.1 (0xfff58a08)
  16 0x7bc5978e LdrInitializeThunk+0x24d(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/build/source/dlls/ntdll/loader.c:3492] in ntdll (0xfff58a68)
  17 0x7b466853 __wine_kernel_init+0x962() [/build/source/dlls/kernel32/process.c:1316] in kernel32 (0xfff59958)
  18 0x7bc5a63b __wine_process_init+0x15a() [/build/source/dlls/ntdll/loader.c:3701] in ntdll (0xfff599d8)
  19 0xf75e1743 wine_init+0x292(argc=0x5, argv=0xfff59f24, error="", error_size=0x400) [/build/source/libs/wine/loader.c:956] in libwine.so.1 (0xfff59a28)
  20 0x7c000c1a main+0x79(argc=<is not available>, argv=<is not available>) [/build/source/loader/main.c:367] in <wine-loader> (0xfff59e78)
  21 0xf73cd5f7 __libc_start_main+0xf6() in libc.so.6 (0x00000000)
0x610a569d: movzbl  0x1(%eax),%ecx
[...]

Is the msys-2.0.dbg for the msys-2.0.dll not properly created?

[fracting]

Hi @andreygursky , see https://bugs.wine-staging.com/show_bug.cgi?id=557 for the debugging symbol issue. It is a known issue that WineDbg does not know dwarf4, and it is a known issue that Win32 gdb does not understand Wine module, so I usually use a combination of WineDbg and Win32 gdb when debugging Msys2 on Wine, switching forth and back again and again, while sometimes rebuild Msys2 program with -gdwarf-2 -gstrict-dwarf like what Wine uses. It's a pain :) Any help is great appreciated!

[andreygursky]

@fracting, thanks for clarifying. BTW, the fact that cygwin dropped the support of WinXP seems to be very unfortunate. Do you know whether RedHat could reconsider that? Had they got substantial benefits from that turn? And where can I follow the progress on the workaround you discussed with Corinna (@github-cygwin?)?

Clear, dwarf4 should be better than dwarf2, but do many users of msys2 really make use of the improvements of the most recent dwarf standard or not really and compiling with dwarf2 could be enough?

[fracting]

@andreygursky sometimes we discuss in Cygwin mailing list [1], sometimes we discuss in Cygwin irc channel [2]. Unfortunately there is no log for irc. I can't answer your question on behalf of RedHat or Cygwin or corrina, but I think the decision has made and it wouldn't be changed since WinXP is lack of security updates.

[1] https://cygwin.com/lists.html
[2] https://cygwin.com/irc.html

[mati865]

Are you still having problems?
I'm still using updated msys2 64bit on Arch (wine staging, tested both 1.9.18 and 1.9.19) and had no problems:

mati865@Arch MSYS ~
$ pacman -Ss msys2-run
msys/msys2-runtime 2.6.0-1 (base) [installed]

[KrullBorg]

yes same problem, tried just now (debian sid, msys2 32bit, wine staging 1.9.22)

[andreygursky]

I've just asked about this on the cygwin mailing list. Let's see, what Cygwin developers say.

[andreygursky]

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

[github-cygwin]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary. Here's what I wrote:

--- snip ---
Ending XP support was announced last year and only a year later we
actually dropped it. So we don't support Windows XP anymore, but we
_would_ support Wine. However, the problem here is not on the Cygwin
side.

It seems Cygwin under Wine was not tested outside of XP compatibility
mode, or Wine doesn't support certain post-XP functions albeit claiming
Vista caompatibility. Cygwin doesn't require any functionality which
isn't available in Vista.
--- snap---

And, of course, we're not uncooperative, but that does _not_ mean we can
easily revert XP compat. The entire code to support XP (and there was
lots of it) has been ripped out of Cygwin since 2.6. Reverting it isn't
the way to go. The right thing to do is to fix Wine. After all, Cygwin
still works nicely on all supported Windows systems and there's
apparently some lack in Wine in terms of Vista and later support.
Unfortunately I don't know what exactly the problem is, I'm not a Wine
expert.

Corinna

[KrullBorg]

ok winxp is dead. but if i set wine to "emulate" >= vista mintty doesn't start anyway

[andreygursky]

@github-cygwin,

If I understood you correctly, previously discussed changes in Cygwin
itself are not considered anymore and from now Wine is really left
alone with this issue?

[missing answer]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary.

No answer I treated as no objection - that's why my summary. But now I'm very glad to hear from you that it is not the case :) So may we ask you relevant questions on some mailing list? Or only on IRC? The problem with later: it is hard to follow due to missing archives.

Unfortunately I don't know what exactly the problem is, I'm not a Wine expert.

Are there some WinAPI tests in Cygwin? Running them would easily reveal the missing or not properly implemented ones in Wine.

[github-cygwin]

On Nov 10 07:54, andreygursky wrote:

@github-cygwin,

If I understood you correctly, previously discussed changes in Cygwin
itself are not considered anymore and from now Wine is really left
alone with this issue?

[missing answer]

On Nov 10 06:56, andreygursky wrote:

Unfortunately, Cygwin seems to be not cooperative: it's only Wine problem now :(

That's a bit unfair in terms of a summary.

No answer I treated as no objection - that's why my summary. But now
I'm very glad to hear from you that it is not the case :) So may we
ask you relevant questions on some mailing list? Or only on IRC? The
problem with later: it is hard to follow due to missing archives.

You're free to discuss the issue on IRC freenode/#cygwin-developers and
the cygwin or cygwin-developer mailing lists. My time to work on Cygwin
got more limited lately so I'd prefer, time being the most limited
resource, to discuss this with developers who are _actively_ going to
debug and fix the problem in Wine.

Unfortunately I don't know what exactly the problem is, I'm not a
Wine expert.

Are there some WinAPI tests in Cygwin? Running them would easily
reveal the missing or not properly implemented ones in Wine.

Sorry, no, but you can use native Linux strace and GDB on Wine to see
what's going on.

Corinna

[mati865]

When installing dash under Wine:

wine: Call from 0x7bc6151c to unimplemented function msys-2.0.dll.__locale_ctype_ptr, aborting

[andreygursky]

@fracting, I'm trying now to build msys2-runtime under wine-staging 2.0~rc5. It fails without any visible reason:

MSYS ~/msys2-runtime makepkg
...
make[4]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygserver'
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygthread.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygthread.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygtls.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygtls.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygwait.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygwait.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o cygxdr.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/cygxdr.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o dcrt0.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/dcrt0.cc
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o shared.o /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/shared.cc
ar rcv libgmon.a gmon.o mcount.o profil.o mcountFunc.o
a - gmon.o
a - mcount.o
a - profil.o
a - mcountFunc.o
ar cru libautomode.a automode.o
ar cru libbinmode.a binmode.o
ar cru libtextmode.a textmode.o
ar cru libtextreadmode.a textreadmode.o
Making version.cc and winver.o
Making version.cc and winver.o
2017-01-20 17:56
2017-01-20 17:56
Version 2.6.0
Version 2.6.0
c++wrap -pipe -O2 -g -ggdb -fno-rtti -fno-exceptions -fno-use-cxa-atexit -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -MMD -Werror -fmerge-constants -ftracer -c -o version.o version.cc
g++ -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/libstdc++-v3/src/.libs -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/libstdc++-v3/libsupc++/.libs -L/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin -isystem /home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/include -B/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/ -isystem /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/targ-include -isystem /home/andrey/msys2-runtime/src/msys2-runtime/newlib/libc/include    -pipe -O2 -g -ggdb \
-mno-use-libstdc-wrappers -L/usr/lib/w32api \
-Wl,--gc-sections -nostdlib -Wl,-Tcygwin.sc -static \
-Wl,--heap=0 -Wl,--out-implib,msysdll.a -shared -o msys0.dll \
-e _dll_entry@12 msys.def advapi32.o arc4random_stir.o assert.o autoload.o base64.o bsdlib.o ctype.o cxx.o cygheap.o cygthread.o cygtls.o cygwait.o cygxdr.o dcrt0.o debug.o devices.o dir.o dlfcn.o dll_init.o dtable.o environ.o errno.o exceptions.o exec.o external.o fcntl.o fenv.o fhandler.o fhandler_clipboard.o fhandler_console.o fhandler_dev.o fhandler_disk_file.o fhandler_dsp.o fhandler_fifo.o fhandler_floppy.o fhandler_mailslot.o fhandler_netdrive.o fhandler_nodevice.o fhandler_proc.o fhandler_process.o fhandler_procnet.o fhandler_procsys.o fhandler_procsysvipc.o fhandler_random.o fhandler_raw.o fhandler_registry.o fhandler_serial.o fhandler_socket.o fhandler_tape.o fhandler_termios.o fhandler_tty.o fhandler_virtual.o fhandler_windows.o fhandler_zero.o flock.o fnmatch.o fork.o fts.o ftw.o getopt.o glob.o glob_pattern_p.o globals.o grp.o heap.o hookapi.o inet_addr.o inet_network.o init.o ioctl.o ipc.o kernel32.o ldap.o libstdcxx_wrapper.o localtime.o lsearch.o malloc_wrapper.o minires-os-if.o minires.o miscfuncs.o mktemp.o mmap.o msg.o msys2_path_conv.o mount.o net.o netdb.o nfs.o nftw.o nlsfuncs.o ntea.o passwd.o path.o pinfo.o pipe.o poll.o posix_ipc.o pseudo-reloc.o pthread.o quotactl.o random.o regcomp.o regerror.o regexec.o regfree.o registry.o resource.o rexec.o rcmd.o scandir.o sched.o sec_acl.o sec_auth.o sec_helper.o sec_posixacl.o security.o select.o sem.o setlsapwd.o shared.o shm.o sigfe.o signal.o sigproc.o smallprint.o spawn.o strace.o strfmon.o strfuncs.o strptime.o strsep.o strsig.o sync.o syscalls.o sysconf.o syslog.o termios.o thread.o timer.o times.o tls_pbuf.o tty.o uinfo.o uname.o wait.o wincap.o window.o winf.o xsique.o  malloc.o acoshl.o acosl.o asinhl.o asinl.o atan2l.o atanhl.o atanl.o cabsl.o cacosl.o cargl.o casinl.o catanl.o cbrtl.o ccosl.o ceill.o cephes_emath.o cexpl.o cimagl.o clog10l.o clogl.o conjl.o copysignl.o coshl.o cosl.o cosl_internal.o cossin.o cpowl.o cprojl.o creall.o csinl.o csqrtl.o ctanl.o erfl.o exp10l.o exp2l.o expl.o expm1l.o fabsl.o fdiml.o finite.o floorl.o fmal.o fmaxl.o fminl.o fmodl.o frexpl.o ilogbl.o internal_logl.o isinf.o isnan.o ldexpl.o lgammal.o llrint.o llrintf.o llrintl.o llroundl.o log10l.o log1pl.o log2l.o logbl.o logl.o lrint.o lrintf.o lrintl.o lroundl.o modfl.o nanl.o nearbyint.o nearbyintf.o nearbyintl.o nextafterl.o nexttoward.o nexttowardf.o pow10l.o powil.o powl.o remainder.o remainderf.o remainderl.o remquol.o rint.o rintf.o rintl.o roundl.o scalbl.o scalbnl.o sinhl.o sinl.o sinl_internal.o sqrtl.o tanhl.o tanl.o tgammal.o truncl.o  version.o winver.o \
 /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygserver/libcygserver.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libm/libm.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libc/libc.a \
-lgcc /usr/lib/w32api/libkernel32.a /usr/lib/w32api/libntdll.a -Wl,-Map,msys.map
+ objcopy -R .gnu_debuglink_overlay --add-gnu-debuglink=/dev/null --only-keep-debug msys0.dll msys-2.0.dbg
+ objcopy -g --add-gnu-debuglink=msys-2.0.dbg msys0.dll
+ objcopy -R .gnu_debuglink_overlay --set-section-flag .gnu_debuglink=contents,readonly,debug,noload --change-section-address .gnu_debuglink=0x612e4000 msys0.dll
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/mkimport --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --replace=atexit= --replace=timezone= --replace=__xdrrec_getrec= --replace=__xdrrec_setnonblock= --replace=xdr_array= --replace=xdr_bool= --replace=xdr_bytes= --replace=xdr_char= --replace=xdr_double= --replace=xdr_enum= --replace=xdr_float= --replace=xdr_free= --replace=xdr_hyper= --replace=xdr_int= --replace=xdr_int16_t= --replace=xdr_int32_t= --replace=xdr_int64_t= --replace=xdr_int8_t= --replace=xdr_long= --replace=xdr_longlong_t= --replace=xdr_netobj= --replace=xdr_opaque= --replace=xdr_pointer= --replace=xdr_reference= --replace=xdr_short= --replace=xdr_sizeof= --replace=xdr_string= --replace=xdr_u_char= --replace=xdr_u_hyper= --replace=xdr_u_int= --replace=xdr_u_int16_t= --replace=xdr_u_int32_t= --replace=xdr_u_int64_t= --replace=xdr_u_int8_t= --replace=xdr_u_long= --replace=xdr_u_longlong_t= --replace=xdr_u_short= --replace=xdr_uint16_t= --replace=xdr_uint32_t= --replace=xdr_uint64_t= --replace=xdr_uint8_t= --replace=xdr_union= --replace=xdr_vector= --replace=xdr_void= --replace=xdr_wrapstring= --replace=xdrmem_create= --replace=xdrrec_create= --replace=xdrrec_endofrecord= --replace=xdrrec_eof= --replace=xdrrec_skiprecord= --replace=xdrstdio_create= --replace=acl=_acl32 --replace=aclcheck=_aclcheck32 --replace=aclfrommode=_aclfrommode32 --replace=aclfrompbits=_aclfrompbits32 --replace=aclfromtext=_aclfromtext32 --replace=aclsort=_aclsort32 --replace=acltomode=_acltomode32 --replace=acltopbits=_acltopbits32 --replace=acltotext=_acltotext32 --replace=chown=_chown32 --replace=facl=_facl32 --replace=fchown=_fchown32 --replace=fcntl=_fcntl64 --replace=fdopen=_fdopen64 --replace=fgetpos=_fgetpos64 --replace=fopen=_fopen64 --replace=freopen=_freopen64 --replace=fseeko=_fseeko64 --replace=fsetpos=_fsetpos64 --replace=fstat=_fstat64 --replace=ftello=_ftello64 --replace=ftruncate=_ftruncate64 --replace=getegid=_getegid32 --replace=geteuid=_geteuid32 --replace=getgid=_getgid32 --replace=getgrent=_getgrent32 --replace=getgrgid=_getgrgid32 --replace=getgrnam=_getgrnam32 --replace=getgroups=_getgroups32 --replace=getpwuid=_getpwuid32 --replace=getpwuid_r=_getpwuid_r32 --replace=getuid=_getuid32 --replace=initgroups=_initgroups32 --replace=lchown=_lchown32 --replace=lseek=_lseek64 --replace=lstat=_lstat64 --replace=mknod=_mknod32 --replace=mmap=_mmap64 --replace=open=_open64 --replace=setegid=_setegid32 --replace=seteuid=_seteuid32 --replace=setgid=_setgid32 --replace=setgroups=_setgroups32 --replace=setregid=_setregid32 --replace=setreuid=_setreuid32 --replace=setuid=_setuid32 --replace=stat=_stat64 --replace=tmpfile=_tmpfile64 --replace=truncate=_truncate64 libmsys-2.0.a msysdll.a _cygwin_crt0_common.o atexit.o cygwin_attach_dll.o cygwin_crt0.o dll_entry.o dll_main.o dso_handle.o libcmain.o premain0.o premain1.o premain2.o premain3.o pseudo-reloc-dummy.o
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a pthread.o thread.o libpthread.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a bsdlib.o libutil.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/newlib/libm/libm.a acoshl.o acosl.o asinhl.o asinl.o atan2l.o atanhl.o atanl.o cabsl.o cacosl.o cargl.o casinl.o catanl.o cbrtl.o ccosl.o ceill.o cephes_emath.o cexpl.o cimagl.o clog10l.o clogl.o conjl.o copysignl.o coshl.o cosl.o cosl_internal.o cossin.o cpowl.o cprojl.o creall.o csinl.o csqrtl.o ctanl.o erfl.o exp10l.o exp2l.o expl.o expm1l.o fabsl.o fdiml.o finite.o floorl.o fmal.o fmaxl.o fminl.o fmodl.o frexpl.o ilogbl.o internal_logl.o isinf.o isnan.o ldexpl.o lgammal.o llrint.o llrintf.o llrintl.o llroundl.o log10l.o log1pl.o log2l.o logbl.o logl.o lrint.o lrintf.o lrintl.o lroundl.o modfl.o nanl.o nearbyint.o nearbyintf.o nearbyintl.o nextafterl.o nexttoward.o nexttowardf.o pow10l.o powil.o powl.o remainder.o remainderf.o remainderl.o remquol.o rint.o rintf.o rintl.o roundl.o scalbl.o scalbnl.o sinhl.o sinl.o sinl_internal.o sqrtl.o tanhl.o tanl.o tgammal.o truncl.o libm.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a dlfcn.o libdl.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a minires.o libresolv.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a posix_ipc.o librt.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a sec_posixacl.o libacl.a
perl -p -e 'BEGIN{binmode(STDIN); binmode(STDOUT);}; s/msys-2.0/msys0/g' < libmsys-2.0.a > libmsys0.a
/home/andrey/msys2-runtime/src/msys2-runtime/winsup/cygwin/speclib --cpu=i686 --ar=ar --as=as --nm=nm --objcopy=objcopy --exclude='cygwin' --exclude='msys' --exclude='(?i:dll)' --exclude='reloc' --exclude='^main$' --exclude='^_main$' libmsys-2.0.a /home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin/libm.a libpthread.a libutil.a -v libc.a
make[3]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup/cygwin'
make[2]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys/i686-pc-msys/winsup'
make[1]: *** [Makefile:9464: all-target-winsup] Error 2
make[1]: Leaving directory '/home/andrey/msys2-runtime/src/build-i686-pc-msys'
make: *** [Makefile:883: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

MSYS ~/msys2-runtime

Any clue?

[andreygursky]

Aha, https://github.com/Alexpux/MSYS2-packages/issues/421#issuecomment-199046874 solves the build failure. @Alexpux, can you build msys2-runtime with mingw-w64-cross-crt-clang-git?

[andreygursky]

@Alexpux, do you know, is it hard to not strip debuginfos from msys-2.0.dll into separate msys-2.0.dbg? I've rebuilt mintty with dwarf-2 debuginfos (which are not splitted by its simple Makefile) and backtraces are there.

[andreygursky]

OK, it was enough to comment out a line in winsup/cygwin/Makefile, where winsup/cygwin/dllfixdbg script is called:

# Rule to build msys-2.0.dll
$(TEST_DLL_NAME): $(LDSCRIPT) dllfixdbg $(DLL_OFILES) $(LIBSERVER) $(LIBC) $(LIBM) $(API_VER) Makefile $(VERSION_OFILES)
    $(CXX) $(CXXFLAGS) \
    -mno-use-libstdc-wrappers -L${WINDOWS_LIBDIR} \
    -Wl,--gc-sections $(nostdlib) -Wl,-T$(firstword $^) -static \
    -Wl,--heap=0 -Wl,--out-implib,msysdll.a -shared -o $@ \
    -e $(DLL_ENTRY) $(DEF_FILE) $(DLL_OFILES) $(VERSION_OFILES) \
    $(MALLOC_OBJ) $(LIBSERVER) $(LIBM) $(LIBC) \
    -lgcc $(DLL_IMPORTS) -Wl,-Map,msys.map
    #@$(word 2,$^) $(OBJDUMP) $(OBJCOPY) $@ ${patsubst %0.dll,%-2.0.dbg,$@} # <--- HERE
    @ln -f $@ new-$(DLL_NAME)

Now I have verbose backtrace.

[projectgus]

Stumbled across this problem today. FWIW, I think the matching wine bug is here:
https://bugs.winehq.org/show_bug.cgi?id=40528

[jpcima]

When I try to run anything in Wine I get this error.
DsEnumerateDomainTrustsW not found. It's supposed to be a function of netapi32.

000b:fixme:winediag:start_process Wine Staging 3.4 is a testing version containing experimental patches. 000b:fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org. wine: cannot find L"C:\\windows\\system32\\winemenubuilder.exe" 000b:err:wineboot:ProcessRunKeys Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (2) 0030:fixme:ntdll:NtSetInformationToken unimplemented class 4 0030:fixme:ntdll:NtQueryInformationProcess (process=0xffffffffffffffff) Unimplemented information class: ProcessSessionInformation 0030:fixme:advapi:GetWindowsAccountDomainSid (0xffffc230 0x15e08 0xffffc228): semi-stub 29 [main] bash 47 C:\msys64\usr\bin\bash.exe: *** fatal error - couldn't dynamically determine load address for 'DsEnumerateDomainTrustsW' (handle 0x7F24DC3D0000), Win32 error 127 Stack trace: Frame Function Args 000FFFFC450 0018007172E (0018022C184, 0018022CDB9, 0000000000F, 000FFFFB270) 000FFFFC450 00180046699 (00000000000, 00000000000, 00000000000, 00180020010) 000FFFFC450 001800466D2 (0018020254D, 7F24DC3D0000, 0000000000F, 000FFFFC450) 000FFFFC450 0018004158E (0018020254D, 7F24DC3D0000, 0000000000F, 000FFFFC450) End of stack trace

[TBBle]

Looking into this, both the IRC log above and the WineHQ discussion at 40528, it appears to me that the call at Cygwin path.cc#4406 to fcwd_access_t::SetDirHandleFromBufferPointer is unnecessary under Wine, since Wine does not (from what I can see in Wine's SetCurrentDirectory and RtlSetCurrentDirectory_U implementations) maintain the FAST_CWD structure that the fcwd_access_t-related code in Cygwin is attempting to manipulate.

The suggestion of reverting ffcef70 is not strictly correct, as it would reinstate other pre-Vista behaviours.

Instead, simply changing fcwd_access_t::SetDirHandleFromBufferPointer (which is already doing version detection) to be a no-op should resolve this issue. Suppressing the complaints from find_fast_cwd at the same time would be nice.

The reason I think this is a Cygwin issue, rather than a Wine issue, is that Cygwin has the [claim]:(https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;hb=HEAD#l4372)

utilizing the fact that the buffer address in the user process parameter block is actually pointing to the buffer in that FAST_CWD structure.

That's an internal Windows detail, and under Wine, that process parameter block's buffer is a static per-process buffer, rather than being switched out each time FAST_CWD is switched out.

To make this work on the Wine side only, Wine would have to have a dummy object that find_fast_cwd_pointer could find, replace with a newly-allocated fcwd_access_t, and then free the dummy object. This doesn't seem like a sensible path forward to me.

[fracting]

Hi @TBBle , I think you are right about Cygwin. Two years ago I was discussing this with Cygwin maintainer and she was happy to change Cygwin to make it work better on Wine, however it was a shame that I stopped my work course I moved to a foreign country with a lot of changes in work and life. If anyone is willing to communicate with Cygwin maintainer, I guess she is still happy to help, either reviewing Cygwin patch or maybe even offering a solution. Sorry I'm not able to pick this up by myself in any near future, but if anyone work on it that would be greatly appreciated!

@TBBle if you are in Sydney I should buy you a coffee/beer! :)

[TBBle]

I've had a shot at creating a simple fix, as per my description above, at https://github.com/TBBle/MSYS2-packages/tree/msys2-runtime-wine-cwd-support

I've installed it locally, but don't actually have a running Wine environment to test it in. I might try and test it out this weekend if no one else gets to it first, but I'll need to either set up virtualisation on my home PC, or find a spare machine in the office that I can temporarily turn into an Ubuntu desktop.

[andyneff]

@TBBle Not sure if you use dockers, but this(source) is the docker I put together to get wine-staging and the old msys running. It should be relatively simple to run this docker and just copy your files instead.

Just add your files to the /home/wine/drive_c directory in the container, and then you should have your version of MSYS2 to test against.

If you are familiar with docker, this could be an easier alternative to setting up a VM for you (Well, technically it is a VM in the background on Windows/macOS, but that's all transparent to you!)

[TBBle]

Ah, lovely, that's exactly what I needed. If I'm reading the code and ISSUES.md correctly, it will give me MSYS2 from 20160719, and Wine Staging 2.4.0-3, and then I could pacman -Syuu and replace the libmsys-2.0.dll and it would validate my fix.

[TBBle]

Okay, it didn't work. I'm going to need to get a proper Wine environment set up since the Wine Debugger doesn't seem to work from Docker (I don't seem to be able to type into it)

[TBBle]

I got X11 going, and I still can't access the debugger, but I confirmed something changed. The error went from

wine: Unhandled page fault on read access to 0x71c795a8 at address 0x18018ebc3 (thread 002e), starting debugger...

to

wine: Unhandled page fault on read access to 0x00000020 at address 0x7bc4af28 (thread 0032), starting debugger...

So it's gone from reading something it shouldn't, to dereferencing a nullptr.

Edit: The nullptr turned out to be peb.FastPebLock. I thought b31583770f074ca343e00f6c2be19b831d6ad90e fixed this in 2017, c.f. comment 7 on the WineHQ bug. A bit of poking around suggests the Cygwin code should be calling RtlAcquirePebLock and RtlReleasePebLock instead, as that's the API exposed by ntdll.dll.

Second Edit: Oh! Wine Staging 2.4, not 3.4. Yeah, that predates the peb.FastPebLock fix.

With that worked around, it now simply terminates, sometime after leaving the cwdstuff::init call. So possibly a different issue, and almost certainly needs a native Wine environment so it can be debugged usefully.

I've repushed my MSYS2-packages branch with my current progress.

I might have a go at rebuilding @andyneff 's Docker images with current Wine Staging, as I also want to test a couple of fixes for the DockerFile themselves.

Third Edit: bash --login terminates, with

Directory \drivers\etc does not exist; exiting
If directory name is garbage you need to update your msys package

And bash without --login hits

bash: cut: command not found

but doesn't terminate.

The PATH has not been updated inside bash, and setting it seems to cause things to break. So there's still more work needed, unsure if this is still a CWD issue, of if we're in the realm of other CYGWIN or Wine issues now. I might try the current Wine Staging build and see what it does.

Fourth Edit: I tried with Wine-staging 3.6.0 packages, and starting any of the programs reports:

      9 [main] mintty 86 C:\msys64\usr\bin\mintty.exe: *** fatal error - couldn't dynamically determine load address for 'DsEnumerateDomainTrustsW' (handle 0x7F1E632A0000), Win32 error 127

This error comes from Cygwin's autoload.cc, trigged (I think) internally by Cygwin

Same problem occurs with this version of Wine and the old version of msys2, so that's a different issue. This function is only a stub in Wine, so perhaps the way stubs are generated changed, and the A/W names are not generated, but used to be. Either way, the fix would be as simple as creating real stubs, as ReactOS did.

[TBBle]

DsEnumerateDomainTrustsW is being fixed upstream in Wine, see https://bugs.winehq.org/show_bug.cgi?id=45081

Edit twice: Fix available as part of Wine 3.8.

[TBBle]

Tried with a Wine Staging 3.8 build of @andyneff 's Docker images, which contain MSYS2 from 20160719, so should not suffer the cygwin bug here.

docker build -f ubuntu_14.04.Dockerfile -t tbble/wine_msys64:ubuntu_14.04-3.8.0 --build-arg WINE_VERSION=3.8.0~trusty .

After a long pause, it eventually shows the mintty window with an error:

The Wine logs didn't give anything specifically useful:

PS C:\Users\paulh\Documents\msys2> .\rundocker-x11.ps1
000b:fixme:winediag:start_process Wine Staging 3.8 is a testing version containing experimental patches.
000b:fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
002f:fixme:ntdll:NtSetInformationToken unimplemented class 4
002f:fixme:ntdll:NtQueryInformationProcess (process=0xffffffffffffffff) Unimplemented information class: ProcessSessionInformation
002f:fixme:advapi:GetWindowsAccountDomainSid (0xffffc240 0x2ec18 0xffffc238): semi-stub
002f:fixme:netapi32:DsEnumerateDomainTrustsW ((null), 0x0023, 0xffffc388, 0xffffc374): stub
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x95
0031:fixme:wldap32:ldap_set_optionA Unsupported option: 0x96
002f:fixme:thread:create_user_shared_data_thread Creating user shared data update thread.
002f:fixme:netapi32:NetLocalGroupGetInfo ((null) L"Administrators" 1 0xffffc380) semi-stub!
002f:fixme:netapi32:NetLocalGroupGetInfo ((null) L"Users" 1 0xffffc380) semi-stub!
002f:fixme:ntdll:NtQueryVolumeInformationFile 0xf0: faking volume info
002f:fixme:ntdll:NtQueryVolumeInformationFile 0xf0: faking attribute info
002f:fixme:font:GetCharWidthFloatW 0x70041, 65, 65, 0xffffc554: stub!
002f:fixme:font:GetCharWidthFloatW 0x70041, 945, 945, 0xffffc558: stub!
002f:fixme:font:GetCharWidthFloatW 0x70041, 9472, 9472, 0xffffc55c: stub!
002f:fixme:dwmapi:DwmEnableBlurBehindWindow 0x30038 0xffffc6f0
002f:fixme:dwmapi:DwmExtendFrameIntoClientArea (0x30038, 0xffffc6b0) stub
0031:fixme:ntdll:NtFsControlFile FSCTL_PIPE_IMPERSONATE: impersonating self
Xlib:  extension "MIT-SHM" missing on display "192.168.1.3:0.0".

[andyneff]

@TBBle That screen shot does look familiar.

As far as running wine 3.8, I've never succeeded running wine 3. I am able to get the same result you are when I try. Further more, if I remove the -e DISPLAY to attempt to use it in wineconsole mode, after a long delay, I tried ls, which never worked:

bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
bash-4.3$ ls
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: retry: No child processes
bash: fork: Resource temporarily unavailable
bash-4.3$

I've never been patient enough to get that far... So..

• Good news: is bash is INDEED running!
• Bad news: forking is not working.

---

For debugging:

• You can add --privileged (this give the container all the kernel permissions it could need, /dev, and a few other things). This might help with the debugging. I don't know off hand how to attach a a wine debugger, so.
• You can further disable the container's sandbox with --ipc=host --network=host --pid=host --uts=host in addition to --privileged. In my experience, when the docker container sandbox is getting in the way of be debugging, this almost always solves the problem, as the Shared Memory, Network, process namespace and mount namespace are no longer separate.
• Probably not it: If QT is involved somehow with the MIT-SHM issue, then adding -e QT_X11_NO_MITSHM=1 can help there

[TBBle]

I don't think MIT_SHM is an issue, since that happened with successful runs too. I expect that you can't use shared memory between an X11 Client in a container on a virtual machine, and an X11 Server running on the VM's host. That's too much abstraction to break through. ^_^

At the moment, there's two issues. The Wine 3.x breakage is probably a Wine bug (since it affects old Cygwin); and there's still some other Cygwin issue after the FAST_CWD issue, which is probably also a Cygwin issue (since it affects old Wine).

Both of the above issues could actually be improvements, that revealed a latent bug in the other...

If and when I have some time for this, I might hijack a real host at work, or a non-Docker VM, and try and replicate/track down the 'Cygwin issue', since that seems a higher priority for this project. Particularly after getting past the FAST_CWD, which has been a blocker for years for both MSYS2 and Cygwin, finishing that work seems highly valuable.

[andyneff]

In general, the things I never got working in a container, didn't work when I had Wine installed on my Linux host either.

That being said, I agree your next course of action would be to make sure the container isn't giving you a false failure (or giving you more trouble than it is worth), and to try it on a real VM.

If you ever find a Wine 3.x that gets patched to the point it works, let me know and I'll investigate getting the container to work with that, when I can find the time.

[TBBle]

Getting out of the container is more about putting me in a familiar environment for dev tools etc, a persistent system image I can mess with, and giving me a properly-throwaway environment. I had issues with the Docker for Windows boot-image (which also stores the data) growing too large, and then and failing to reshrink when I removed old data.

[andreygursky]

@TBBle:

At the moment, there's two issues. The Wine 3.x breakage is probably a Wine bug (since it affects old Cygwin)

https://bugs.winehq.org/show_bug.cgi?id=40528 has been just closed.

and the Cygwin fixes are patches 0025 and 0026 at
https://github.com/TBBle/MSYS2-packages/tree/msys2-runtime-wine-cwd-support/
msys2-runtime.

But I don't see your patches here: https://github.com/Alexpux/MSYS2-packages/tree/master/msys2-runtime

Anyway thanks!

[TBBle]

https://bugs.winehq.org/show_bug.cgi?id=40528 was put back into the RESOLVED-NOTOURBUG state a day later, the closing was an accident. That bug is actually tracking this issue, since I'm unaware of a Cygwin-side bug tracker for such things.

As for the patches, I never actually got a working setup, as there were Wine-side issues, and I haven't yet tried again since they were fixed.

My testing indicated that those two patches fixed the FAST_CWD issue, but other problems appeared later, and I wanted to get it all working before pushing the fixes upstream.

That's the status from https://github.com/Alexpux/MSYS2-packages/issues/682#issuecomment-385144098

And then I got distracted for over six months, and never got back to it. Sorry.

[bparker06]

Any updates on this? I still get the FAST_CWD error with the latest msys2 tarball on wine 4.0 stable.

[TBBle]

Not yet. Still somewhere in my personal "interesting things to work on if I find some spare development time" pile, but it's not even the top of that pile, as I'd need a working desktop Linux setup first in order to debug Wine and see why it still fails after I fixed/patched-around the FAST_CWD issue.

I'd also planned on flipping over to upstream Cygwin for further testing, since that's where fixes ought to eventually go.

[justinkb]

One of the more interesting bugs I've come across in my hacking days. Running into this while assembling a cross compiler targeting cygwin. Tried your fix, doesn't work for me at least. It makes that FAST_CWD message go away, but the programs still won't start properly

[alexdelorenzo]

Fixing this bug would allow some cool options to build Windows software on Linux. PyInstaller already runs well on Wine when building Windows packages on Linux, and being able to use Cygwin under Wine would make bundling dependencies for Windows easier.

[mohamed-badaoui]

any update on this one?
Same error if I would like to use git win command for example.