[Bug 10401] New: cygwin programs don't sscanf() properly when -mno-cygwin is used in gcc options
http://bugs.winehq.org/show_bug.cgi?id=10401
Summary: cygwin programs don't sscanf() properly when -mno-cygwin is used in gcc options Product: Wine Version: 0.9.49. Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: emwine@earthlink.net
Created an attachment (id=9089) --> (http://bugs.winehq.org/attachment.cgi?id=9089) testcase project and 2 test binaries
When I upgraded to Winboard version 4.2.7b from 4.2.7a, I got parse errors when the app tried to extract info from an online chess server. I tracked this down as far as I am able-- it appears to be only a definition in the makefile: -mno-cygwin. How that causes the bug, I don't understand, but presumably the only difference between Winboard 4.2.7b and 4.2.7a (which works in wine) is the presence of that option in the makefile.
When -mno-cygwin is present, a call like:
n=sscanf("r-bqk -1 0", "%5c%d%d", str, &i, &j);
only gets the first character into str rather than all 5 like it should, and n becomes 1 with i and j failing to get read.
Attached is a testcase project to illustrate. It includes 2 binaries, the only difference being the presence of -mno-cygwin during the build. (Line 19 in the makefile) To build this testcase, you need the cygwin tools, probably just normal build tools, and to run wbtest.exe, you need cygwin1.dll which I haven't included.
wbtest-nocyg.exe: works properly in wine and in windows
wbtest.exe: works properly in windows, but fails in wine
http://bugs.winehq.org/show_bug.cgi?id=10401
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2008-03-18 21:34:35 --- (Did you get the names of those binaries backwards?)
In the successful case, cygwin1.dll's scanf is called. In the failure case, WINEDEBUG=+all shows no calls between program entry and failure, so I suspect you've linked in a static library that implements sscanf. You'd need to step through that library with a debugger to figure out what's going on.
http://bugs.winehq.org/show_bug.cgi?id=10401
--- Comment #2 from Eric Mullins emwine@earthlink.net 2008-03-19 00:08:22 --- Yes, the names are probably backwards-- the statically linked one is the problematic one (wbtest.exe).
I don't know anything about the cygwin tools aside from using them to build projects. It seems odd to me that different code would get used depending on how sscanf() was linked. But I'll see if I can delve into it further. I was hoping maybe someone active in the Wine project might know a little about cygwin.
http://bugs.winehq.org/show_bug.cgi?id=10401
--- Comment #3 from Eric Mullins emwine@earthlink.net 2008-03-19 11:34:05 --- I discovered that using -mno-cygwin flag means "don't use any cygwin, use Microsoft runtime (MinGW)" and verified this by compiling the testcase using just the MinGW tools and getting the same sscanf() problem. I can also duplicate the issue by compiling the testcase as follows:
cl /MD wbtest.c -o wbtest.exe user32.lib
using Visual C++ 6.0, so the problematic sscanf() code appears to be in the MSVCRT.
Note: using Visual C++ 6.0 and compiling without "/MD" produces a binary that works fine in both windows and Wine, eg:
cl wbtest.c -o wbtest.exe user32.lib
From "cl -help":
/MD link with MSVCRT.LIB
http://bugs.winehq.org/show_bug.cgi?id=10401
Eric Mullins emwine@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |msvcrt Keywords| |testcase Summary|cygwin programs don't |sscanf() incorrect results |sscanf() properly when -mno-|in MSVCRT |cygwin is used in gcc | |options |
--- Comment #4 from Eric Mullins emwine@earthlink.net 2008-03-20 10:13:11 --- Switching to native MSVCRT solves the problem. So I changed component to msvcrt, adjusted the title (removing cygwin, since that's irrelevant), and added keywords.
http://bugs.winehq.org/show_bug.cgi?id=10401
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|msvcrt |-unknown
--- Comment #5 from Dan Kegel dank@kegel.com 2008-03-20 10:26:05 --- I'm not convinced. I don't think the bug is in wine's msvcrt, I think it's in microsoft's static msvcrt, and it's triggered by something in the environment.
It will probably take single-stepping with a debugger to figure this out.
http://bugs.winehq.org/show_bug.cgi?id=10401
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-03-20 10:34:13 --- (In reply to comment #5)
I'm not convinced. I don't think the bug is in wine's msvcrt, I think it's in microsoft's static msvcrt, and it's triggered by something in the environment. It will probably take single-stepping with a debugger to figure this out.
Isn't that obvious if with builtin msvcrt the bug persists but a native one fixes it?
http://bugs.winehq.org/show_bug.cgi?id=10401
--- Comment #7 from Dan Kegel dank@kegel.com 2008-03-20 11:33:54 --- Looking at the relay log I saw no evidence of our msvcrt being called. My theory is that he was linking *statically* to Microsoft's in the problem case.
I could of course be wrong. I usually am...
http://bugs.winehq.org/show_bug.cgi?id=10401
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2008-03-20 12:03:56 --- varargs calls like sscanf don't show up in relay traces.
It's clearly a bug in builtin, the %c format is currently hardcoded to a single char.
http://bugs.winehq.org/show_bug.cgi?id=10401
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |msvcrt Ever Confirmed|0 |1
--- Comment #9 from Dan Kegel dank@kegel.com 2008-03-20 12:05:37 --- Thanks! Setting category back to msvcrt, confirming.
http://bugs.winehq.org/show_bug.cgi?id=10401
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2008-03-21 08:13:30 --- It should be fixed now.
http://bugs.winehq.org/show_bug.cgi?id=10401
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2008-03-21 10:53:36 --- Closing bugs fixed in 0.9.58.
-
wine-bugs＠winehq.org