http://bugs.winehq.org/show_bug.cgi?id=17031
Summary: popen not connecting to stdin / stdout correctly Product: Wine Version: 1.1.13 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: lkcl@lkcl.net
same command run as wine c:/mingw/bin/windres.exe _does_ work, but when run from /bin/sh.exe in msys, it fails.
$ windres.exe --input python_dll.rc --output python_dll.res --output-format=coff c:\mingw\bin\windres.exe: can't popen `c:\mingw\bin\gcc -E -xc -DRC_INVOKED python_dll.rc': Bad file descriptor
this is related to http://bugs.winehq.org/show_bug.cgi?id=16968 which is a slightly more complex test but still involving popen (ultimately).
on 1.0.1, there was no question that this was an out-and-out failure: however, under 1.1.13, #16968 seemed to succeed.
so it would appear that things have simply got... a little bit faster, in 1.1.13, so it "seems" that the problem has "gone away", but it hasn't.
http://bugs.winehq.org/show_bug.cgi?id=17031
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2009-01-19 11:27:33 --- Wicked. Can you try to boil this down further by replacing either windres or gcc with a little synthetic c program?
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #2 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-01-19 11:46:46 --- whoops! :)
=>0 0x7ec28785 MSVCRT_fgetc+0x15(file=(nil)) [/mnt/video/src/wine-1.1.13/build32/dlls/msvcrt/../../../dlls/msvcrt/file.c:2301] in msvcrt (0x0060fc28) 1 0x7ec28990 MSVCRT_fgets+0x60(s=<register ESI not in topmost frame>, size=<register EDI not in topmost frame>, file=(nil)) [/mnt/video/src/wine-1.1.13/build32/dlls/msvcrt/../../../dlls/msvcrt/file.c:2329] in msvcrt (0x0060fc68) 2 0x0040135d in a (+0x135d) (0x0060fec8) 3 0x0040124b in a (+0x124b) (0x0060fef8) 4 0x00401298 in a (+0x1298) (0x0060ff08) 5 0x7ee4a338 start_process+0x98(arg=(nil)) [/mnt/video/src/wine-1.1.13/build32/dlls/kernel32/../../../dlls/kernel32/process.c:904] in kernel32 (0x0060ffe8) 6 0xf7e62b47 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
as i have a patched version of file.c, that's:
int CDECL MSVCRT_fgetc(MSVCRT_FILE* file) { unsigned char *i; unsigned int j; if (file->_cnt>0) { <---- here
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #3 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-01-19 11:49:30 --- Created an attachment (id=18833) --> (http://bugs.winehq.org/attachment.cgi?id=18833) segfault of popen fgets (works fine on msvcrt native)
either the /bin/sh.exe or the gcc.exe will cause a segfault. the gcc.exe one is _supposed_ to simply "get it wrong", as shown on e.g. windres.exe, but i suppose a segfault is better than nothing!
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #4 from Dan Kegel dank@kegel.com 2009-01-19 12:10:04 --- Is that the right attachment? It looks like an earlier test.
http://bugs.winehq.org/show_bug.cgi?id=17031
Luke Kenneth Casson Leighton lkcl@lkcl.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #18833|0 |1 is obsolete| |
--- Comment #5 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-01-19 12:25:51 --- Created an attachment (id=18837) --> (http://bugs.winehq.org/attachment.cgi?id=18837) correct popen test
you're right! i cp'd test.c /tmp in the msys environment, which has /tmp mapped to c:/windows/temp not my unix /tmp :)
http://bugs.winehq.org/show_bug.cgi?id=17031
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=17031
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |msvcrt Ever Confirmed|0 |1
--- Comment #6 from Dan Kegel dank@kegel.com 2009-01-19 17:57:58 --- OK, so: to reproduce:
0. compile the popen test using mingw32, sudo apt-get install mingw32 i586-mingw32msvc-gcc popen.c 1. install msys and mingw from http://mingw.org 2. cd .wine/drive_c/msys/1.0; wine cmd /c msys.bat 3. in the rxvt window that starts up, run the a.exe compiled in step 0 The stack dump shows up in the rxvt window. The crash occurs because popen returns NULL.
To learn more, I did WINEDEBUG=+process,+relay ./a.out in the rxvt window; that caused debug output to come out nicely in the shell where I had started msysm. The log seems to show that popen() is passing the commandline to cmd.exe, which doesn't know what to make of it, and can't execute the requested command.
I tried changing the test to use f = popen("echo world", "r"); and that seemed to make more sense in the +process log, trace:process:CreateProcessW app L"C:\windows\system32\cmd.exe" cmdline L"C:\windows\system32\cmd.exe /c echo world" but popen still returns null.
At this point I realized that the popen in question is msvcrt's. I'll attach the +relay,+process,+msvcrt log, which shows the popen failure. Running with "winetricks vcrun6" and then overriding msvcrt lets my modified test program popen("echo hello") properly, so this part looks like a bona fide msvcrt wine bug.
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #7 from Dan Kegel dank@kegel.com 2009-01-19 17:59:07 --- Created an attachment (id=18846) --> (http://bugs.winehq.org/attachment.cgi?id=18846) +relay,+msvcrt,+process log of popen("echo world", ...)
http://bugs.winehq.org/show_bug.cgi?id=17031
Luke Kenneth Casson Leighton lkcl@lkcl.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msvcrt |-unknown
--- Comment #8 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-01-20 04:59:33 --- apologies i should have also said:
make a symlink between ~/.wine/drive_c/msys/bin to ~/.wine/drive_c/bin and _then_ you'll get an attempt to run /bin/sh.exe working. but yes - it doesn't matter what the command to be executed is.
this bug is also stopping e.g. windres.exe from working as that uses popen to run gcc as well.
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #9 from Dan Kegel dank@kegel.com 2009-01-20 08:34:34 --- Yeah, I tried fooling around like that (I tried copying sh.exe to the current drive's /bin) without luck, but realized it didn't matter...
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #10 from Austin English austinenglish@gmail.com 2009-07-21 14:10:14 --- Is this still an issue in current (1.1.26 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=17031
--- Comment #11 from Luke Kenneth Casson Leighton lkcl@lkcl.net 2009-07-22 03:43:12 --- sorry, dan - the last feedback to the wine-devel mailing list that i got, which accused me of being "lazy", totally discouraged me from doing any further work on Wine.
so, i'm sorry, but i can't answer, and am not that interested in finding out, unless i receive an apology.
http://bugs.winehq.org/show_bug.cgi?id=17031
David De La Harpe Golden david.delaharpe.golden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.delaharpe.golden@gmai | |l.com
--- Comment #12 from David De La Harpe Golden david.delaharpe.golden@gmail.com 2009-07-27 15:44:11 --- I see something very like this with wine 1.1.26 during an emacs w32 build attempt with mingw under wine - windres fails on popen unless I do "winetricks vcrun6"
I'm not really familiar enough with wine or win32 to add anything new, just confirming it still seems to be an issue in 1.1.26
http://bugs.winehq.org/show_bug.cgi?id=17031
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |msvcrt
--- Comment #13 from Dan Kegel dank@kegel.com 2009-07-27 15:57:19 --- Setting component to msvcrt.
http://bugs.winehq.org/show_bug.cgi?id=17031
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #14 from Austin English austinenglish@gmail.com 2010-09-07 14:09:06 CDT --- Is this still an issue in current (1.3.2 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=17031
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #15 from Piotr Caban piotr.caban@gmail.com 2011-06-01 16:34:36 CDT --- I can't reproduce it with current wine. It's probably already fixed. Please retest.
http://bugs.winehq.org/show_bug.cgi?id=17031
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #16 from Piotr Caban piotr.caban@gmail.com 2012-12-13 08:17:23 CST --- Works for me. It was not tested for over a year by anyone else. Marking fixed.
http://bugs.winehq.org/show_bug.cgi?id=17031
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2012-12-21 13:28:51 CST --- Closing bugs fixed in 1.5.20.
-
wine-bugs＠winehq.org