Version: svn (using Devel) Compiler: valgrind and wine built with gcc 4.3.2 test app built with msvc 6 OS: Linux Installed from: Compiled sources The test program test.c #include <string.h> #include <malloc.h> int main(int argc, char **argv) { char *buf = malloc(100); strcpy(buf, "a"); return strlen(buf); } runs under valgrind with no complaint when built with mingw, but when compiled with msvc6 with commandline "cl /zi test.c" and run under valgrind with commandline "valgrind --workaround-gcc296-bugs=yes --trace-children=yes wine test.exe" it produces the warning Conditional jump or move depends on uninitialised value(s) at 0x401086: _strlen (in /home/dank/test2.exe) John Reiser mentioned _strlen in win32 apps in the following patches: http://article.gmane.org/gmane.comp.debugging.valgrind.devel/4306 http://article.gmane.org/gmane.comp.debugging.valgrind.devel/4311 however even when I build his suggested valgrind+wine stack, it still reports that error. (His stack does let me not use --workaround-gcc296-bugs=yes, though, which I otherwise need to avoid lots of error reports about chkstk.)
Created attachment 33102 [details] Test case (.c, .exe, .pdb)
For reference, the script to build Reiser's wine+valgrind stack is at http://kegel.com/valgrind/winegrind-20080706.tgz
Incidentally, I looked at this test case because I ran into the warning Conditional jump or move depends on uninitialised value(s) at 0x6328F6: strlen (strlen.asm:88) when running base_unittests.exe from Chromium under valgrind and wine from svn. (Also: if you're going to try Reiser's wine script, it's best to do it on a pure 32 bit system.)
The errors go away when the test app is linked with a debugging version of the C library using the flags /MDd or /MLd. This is consistent with Reiser's statement about spurious strcmp et al warnings coming from some optimization that confused valgrind. It also suggests a workaround for anyone who really needs one.