https://bugs.winehq.org/show_bug.cgi?id=48891
Bug ID: 48891 Summary: Cannot run any utility from msys2/git-bash Product: Wine Version: 5.5 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: megastallman@gmail.com Distribution: ---
Trying next steps after rebuilding wine-staging-5.5 with a patch, that fixes https://bugs.winehq.org/show_bug.cgi?id=48882
002b:fixme:netapi32:NetUserGetInfo Only implemented for local computer, but remote serverL"\\@" was requested. Cygwin WARNING: Couldn't compute FAST_CWD pointer. This typically occurs if you're using an older Cygwin version on a newer Windows. Please update to the latest available Cygwin version from https://cygwin.com/. If the problem persists, please see https://cygwin.com/problems.html
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #1 from megastallman megastallman@gmail.com --- The same happens with Cygwin:
Running wine-5.5. Trying to run: wine .wine/drive_c/cygwin/bin/bash.exe getting: Cygwin WARNING: Couldn't compute FAST_CWD pointer. This typically occurs if you're using an older Cygwin version on a newer Windows. Please update to the latest available Cygwin version from https://cygwin.com/. If the problem persists, please see https://cygwin.com/problems.html
And nothing works. No shell, terminal hangs and needs "reset". The Cygwin version - is the latest.
https://bugs.winehq.org/show_bug.cgi?id=48891
Roman Pišl rpisl@seznam.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rpisl@seznam.cz
--- Comment #2 from Roman Pišl rpisl@seznam.cz --- If I understand correctly, this is still again and again the same bug 40528 summarized in https://bugs.winehq.org/show_bug.cgi?id=40528#c12. I'd rather hear actual news about msys2/cygwin there ;-)
https://bugs.winehq.org/show_bug.cgi?id=48891
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- (In reply to megastallman from comment #0)
Trying next steps after rebuilding wine-staging-5.5 with a patch, that fixes https://bugs.winehq.org/show_bug.cgi?id=48882
I wouldn't necessarily trust that this patch was sufficient, or is still sufficient, to entirely work around that bug. The warning regarding FAST_CWD is likely an indication that it isn't.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #4 from megastallman megastallman@gmail.com --- Hi Zebedia! - Regarding my fist message - using wine-staging-5.5, with your patch. - Regarding the second - wine-5.5, packaged by OpenSUSE, without your patch.
And result is still the same.
Hi Roman! Moving to the original bug's branch...
https://bugs.winehq.org/show_bug.cgi?id=48891
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #5 from Damjan Jovanovic damjan.jov@gmail.com --- Try running:
wineconsole bash.exe
You might find fork() breaks. In that case try running a non-forking bash builtin command like "pwd".
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #6 from megastallman megastallman@gmail.com --- You are right, Damjan! Cygwin WARNING: Couldn't compute FAST_CWD pointer. This typically occurs if you're using an older Cygwin version on a newer Windows. Please update to the latest available Cygwin version from https://cygwin.com/. If the problem persists, please see https://cygwin.com/problems.html
0 [main] bash 1017 dofork: child -1 - CreateProcessW failed for 'C:\msys32\usr\bin\bash.exe', errno 13 bash: fork: Permission denied bash-4.4$ bash-4.4$ pwd / =================== Looks like there is also the fork() problem.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #7 from Damjan Jovanovic damjan.jov@gmail.com --- fork() was breaking in several places. The first problem was that a thread that's involved in freezing all other threads and copying their memory to the child never gets started, and it doesn't get started because Cygwin expects an APC to fire during process startup, and on Wine it doesn't. That's fixed now.
I only vaguely remember the current fork() problem, where the child is created, the parent's memory is copied to it, but then some sanity checks are performed, and in file winsup/cygwin/cygheap.h, it expects to find the symbol _cygheap_start at the same address in both parent and child:
extern char _cygheap_start[] __attribute__((section(".idata")));
but on Wine they're at different addresses, which is detected by get_cygwin_startup_info() in dcrt0.cc, and causes fork() to fail. Maybe Wine doesn't lay out .idata sections in binaries at their correct addresses.
https://bugs.winehq.org/show_bug.cgi?id=48891
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Component|-unknown |loader Status|UNCONFIRMED |NEW Keywords| |source
--- Comment #8 from Damjan Jovanovic damjan.jov@gmail.com --- To reproduce:
Install Cygwin.
cd cygwin/bin
wineconsole --backend=curses bash.exe
then run this in there:
./ls.exe
*** fatal error - cygheap base mismatch detected - 0x9C7408/0x917408.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #9 from megastallman megastallman@gmail.com --- Buit wine-5.6 recently. Without any patches.
Tried running ./ls.exe with 2 different way. It crashes so fast, that I couldn't read the messages.
wineconsole --backend=curses bash.exe - Gives me 2 lines with errors
wine start bash - Actually lists the current /usr/bin directory and dies very quickly also.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #10 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Damjan Jovanovic from comment #8)
To reproduce:
Install Cygwin.
cd cygwin/bin
wineconsole --backend=curses bash.exe
then run this in there:
./ls.exe
*** fatal error - cygheap base mismatch detected - 0x9C7408/0x917408.
This error is FreeBSD-specific, possibly a result of commit e5f6637eece2b9d5b42b3f99da3627d7bb140a7e.
On Linux Cygwin gets quite far actually: $ wineconsole (starts in separate window. Continue in that window.) C:\cygwin\bin>bash (prompt changes to bash:) bash-4.4$ ./ls.exe (prints out file listing, and exits to wineconsole) ("fixme:console:GetConsoleProcessList (0xdeadbeef,0): stub" printed in Linux's bash, the one wineconsole was started from) C:\cygwin\bin>
So on Linux, Cygwin's bash does seem to work, but it can only run a single command before exiting, possibly due to that GetConsoleProcessList() stub.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #11 from Roman Pišl rpisl@seznam.cz --- Hello, I'd like to help with this, but if clean Wine 5.6 is compiled from source it always crashes with "005c:err:seh:setup_exception stack overflow 8576 bytes in thread 005c.." when starting any cygwin binary. If I use distribution Wine 5.6 I can confirm the behavior. I am on Debian Linux.
I implemented GetConsoleProcessList() for ConEmu and sent patches, they are still on the list, see bug 48760.
https://bugs.winehq.org/show_bug.cgi?id=48891
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #12 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Please don't make meta bugs or discuss multiple issues.
FAST_CWD issue is bug 40528.
Define what this bug is about and change the title accordingly, or resolve it duplicate of bug 40528.
Open separate bugs for other issue.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #13 from megastallman megastallman@gmail.com --- Hi Roman! Tried the patches on wine-5.6, still the same. Programs run, but close the console immediately. Also, cygwin installer gets broken on postinstall scripts.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #14 from Roman Pišl rpisl@seznam.cz --- I do agree with Olivier, this bug should be about a more specific problem. The problem with stack exception is 64bit-specific, occurs on distribution and compiled Wine 5.6 and I'll open a new bug for this.
My suggestion is to rename this bug to "Bash from Cygwin/msys2 terminates after first command". This occurs on both 32bit and 64bit versions.
The FAST_CWD issue is already bug 40528.
Then I see no other issue on Wine 5.6 now.
https://bugs.winehq.org/show_bug.cgi?id=48891
megastallman megastallman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Cannot run any utility from |Bash from Cygwin/msys2 |msys2/git-bash |terminates after first | |command
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #15 from megastallman megastallman@gmail.com --- Renamed
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #16 from Damjan Jovanovic damjan.jov@gmail.com --- Cygwin's "strace" command turned out to be very useful: strace -o ../strace.txt command
What we see, comparing dofork() in code with logging output, is that this line: syscall_printf ("%R = fork()", res); logs: ... forkme 1023 ... dofork(): 0 = fork(); ... forkme 1024 ... dofork(): 0 = fork();
So both the parent and the child think they are the child. Interestingly the parent can't write to the terminal, but if you make a sample application in which the child from fork() creates a file with the return value from GetCurrentProcessId() in the filename, 2 files get created.
fork() calls dofork(), whose res comes from:
---snip--- if (!ischild) res = grouped.parent (stackp); else { res = grouped.child (stackp); in_forkee = false; ischild = true; /* might have been reset by fork mem copy */ } ---snip---
It's grouped.parent() that return 0 for the parent, and we know ischild is correct because strace logging from grouped.parent() happens and happens only once.
grouped.parent() is the frok::parent() method, which always return -1 on failure. It returned 0, so it doesn't think it failed. The success return value comes from child_pid, which is set by:
---snip--- child_pid = cygwin_pid (pi.dwProcessId); ---snip---
pi.dwProcessId is definitely valid. What does cygwin_pid() do, that results in it returning 0?
---snip--- /* Convert Windows WINPID into Cygwin PID. Utilize the "winpid.WINPID" symlinks created for each process. The symlink contains the Cygwin PID as target. Return 0 if no "winpid.WINPID" symlink exists for this WINPID. */ pid_t cygwin_pid (DWORD dwProcessId) { WCHAR sym_name[24]; WCHAR pid_name[12]; UNICODE_STRING sym_str; UNICODE_STRING pid_str; OBJECT_ATTRIBUTES attr; HANDLE sym_hdl; NTSTATUS status;
__small_swprintf (sym_name, L"winpid.%u", dwProcessId); RtlInitUnicodeString (&sym_str, sym_name); InitializeObjectAttributes (&attr, &sym_str, OBJ_CASE_INSENSITIVE, get_shared_parent_dir (), NULL); status = NtOpenSymbolicLinkObject (&sym_hdl, SYMBOLIC_LINK_QUERY, &attr); if (!NT_SUCCESS (status)) return 0; RtlInitEmptyUnicodeString (&pid_str, pid_name, sizeof pid_name - sizeof (WCHAR)); status = NtQuerySymbolicLinkObject (sym_hdl, &pid_str, NULL); NtClose (sym_hdl); if (!NT_SUCCESS (status)) { system_printf ("NtOpenSymbolicLinkObject: %y, PID %u, ret 0", status, dwProcessId); return 0; } pid_str.Buffer[pid_str.Length / sizeof (WCHAR)] = L'\0'; pid_t ret = (pid_t) wcstoul (pid_str.Buffer, NULL, 10); return ret; } ---snip---
There are 3 paths out of the function. The middle one would log an NtOpenSymbolicLinkObject failure (it's a typo, it's actually NtQuerySymbolicLinkObject fails), but that's not visible in the strace. Therefore it's the first or the last return that returned 0.
So one of the following took place: 1. NtOpenSymbolicLinkObject() failed, returning 0 without logging anything. 2. NtQuerySymbolicLinkObject() succeeded but returned "0" which was parsed to 0 by wcstoul() and return to the caller, either due to a Wine bug in it, or another Wine bug when the symbolic link was created/stored.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #17 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 67113 --> https://bugs.winehq.org/attachment.cgi?id=67113 Hack to disable create_symlink() access checks in wineserver
It's definitely (1) from my prior analysis, NtCreateSymbolicLink() previously failed, then causing NtOpenSymbolicLink() to fail on that link, causing 0 to get returned to the parent process due to a lack of error checking in Cygwin (which should return -1 and set errno).
The reason NtCreateSymbolicLink() fails is that wineserver returns STATUS_ACCESS_DENIED, and the reason that it does that is that the access rights checks between symlink_map_access() and check_object_access() go wrong somewhere. I haven't figured that out yet.
However the attached hack works around that for now, by disabling access checks for symbolic links. It successfully gets fork() to return the right PID to the parent instead of 0, and gets the shell (bash, dash) to remain open after running its first command and able to run many more commands :-).
https://bugs.winehq.org/show_bug.cgi?id=48891
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|loader |wineserver
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #18 from megastallman megastallman@gmail.com --- Thanks Damjan! Looks like it works finally.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #19 from Dmitry Timoshkov dmitry@baikal.ru --- Created attachment 67128 --> https://bugs.winehq.org/attachment.cgi?id=67128 patch
Attached patch fixes STATUS_ACCESS_DENIED error by granting full access to the object's owner. Incidentally it also fixes a test previously marked as todo_wine.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #20 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Dmitry Timoshkov from comment #19)
Created attachment 67128 [details] patch
Attached patch fixes STATUS_ACCESS_DENIED error by granting full access to the object's owner. Incidentally it also fixes a test previously marked as todo_wine.
This patch also fixes Cygwin.
Thank you so much Dmitry, I was dreading having to research how Windows's access checks work!
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #21 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Damjan Jovanovic from comment #20)
This patch also fixes Cygwin.
Thank you so much Dmitry, I was dreading having to research how Windows's access checks work!
Thanks for the testing. I guess this patch probably needs tests, are you willing to work on adding some?
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #22 from megastallman megastallman@gmail.com --- Thanks Dmitry! Your patch works as well.
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #23 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Dmitry Timoshkov from comment #21)
(In reply to Damjan Jovanovic from comment #20)
This patch also fixes Cygwin.
Thank you so much Dmitry, I was dreading having to research how Windows's access checks work!
Thanks for the testing. I guess this patch probably needs tests, are you willing to work on adding some?
Maybe. What would I test? NtCreateSymbolicLink() or the authorization APIs?
https://bugs.winehq.org/show_bug.cgi?id=48891
--- Comment #24 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Damjan Jovanovic from comment #23)
Thanks for the testing. I guess this patch probably needs tests, are you willing to work on adding some?
Maybe. What would I test? NtCreateSymbolicLink() or the authorization APIs?
Have a look at the test fixed by this patch: at least WRITE_OWNER bit is not tested. Another set of tests could be added to test_kernel_objects_security() specifically for symbolic links. In general a test that replicates the call to NtCreateSymbolicLink() that msys2 performs would be nice to have as well.
https://bugs.winehq.org/show_bug.cgi?id=48891
Jinoh Kang jinoh.kang.kr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=48891
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |fgouget@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=48891
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |31e984a09d6bb9ce774da9bee7e | |24eea2a379f75 Status|NEW |RESOLVED
--- Comment #25 from Damjan Jovanovic damjan.jov@gmail.com --- Patch committed, resolving fixed :-).
Thank you for your participation, and a big thank you to Dmitry for debugging the authorization APIs.
https://bugs.winehq.org/show_bug.cgi?id=48891
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #26 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.11.
https://bugs.winehq.org/show_bug.cgi?id=48891
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=48891
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |---
--- Comment #27 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.3.