Re: Does testbot's MingW miscompile winmm:midi tests?
* On Fri, 10 Sep 2010, joerg-cyril.hoe...@t-systems.com wrote: > > Now what to do next? > - uninitialised memory issue? > - bad MingW or includes on test.winehq? > > How do MingW on test.winehq and testbot.winehq differ? Difference of primary interest would be in the compiler versions and then in configure options, I guess. Reports on test.wineh.org says the details [1]: | Build version | | Using built-in specs. | Target: i586-mingw32msvc | Configured with: /home/ron/devel/debian/mingw32/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure |-v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ |--enable-threads --enable-sjlj-exceptions --disable-multilib |--enable-version-specific-runtime-libs | Thread model: win32 | gcc version 4.2.1-sjlj (mingw32-2) But testbot.winehq.org seems to provide such full info [2]. The only stuff I can find is the name of the cross-compiler binary used: | i686-pc-mingw32-gcc Lets compare it to the first one: | i586-mingw32msvc So at least it's clear both compilers were built using different build environments and different targets (msvc vs gcc; i586 vs i686). Seems like testbot.winehq.org should be enhanced to be a bit verbose. Is it's code available? I haven't found one in Wine's git repo [3]. S. [1] http://test.winehq.org/data/2c4b08176bf43c1a7a3dd922432e6efae33168cb/me_s2/version.html [2] https://testbot.winehq.org/JobDetails.pl?Key=5184&log_101=1#k101 [3] http://source.winehq.org/git/
Does testbot's MingW miscompile winmm:midi tests?
Hi, the subject should read "Does test.winehq's MingW miscompile winmm:midi tests?" Here's the summary of Saulius Krazuckas' testing on WinME machines: - winmm_test.exe midi fails with INVALPARAM on test.winehq.org (winmm_test.exe extracted from winetest.exe) + No failures with a binary compiled on testbot.winehq.org, e.g. testbot job #4989 + No failures with a MSVC-compiled binary Now what to do next? - uninitialised memory issue? - bad MingW or includes on test.winehq? How do MingW on test.winehq and testbot.winehq differ? Regards, Jörg Höhle
Does testbot's MingW miscompile winmm:midi tests?
Hi, please excuse the numerous errors in my last message: >> Likewise, Octavian Voicu's machines saw no failure with the MSVC It's actually Saulius Krasuckas' machines. >> binary, but constantly produce red color on testbot. >When you say "red color on testbot" you mean 'red' on test.winehq.org? Yes, indeed. I also got the subject wrong. "Does test.winehq's MingW miscompile winmm:midi tests?" Jörg Höhle
Re: Does testbot's MingW miscompile winmm:midi tests?
On 09/06/2010 11:02 AM, joerg-cyril.hoe...@t-systems.com wrote: Hi, on test.winehq, WinME systems always report 8 rc=MMSYSERR_INVALPARAM errors. However, when running a MSVC compiled binary (as found in testbot job #4990), no such error occurs. Paul Vriens wrote: I only see those 8 errors with the winetest executable from test.winehq.org. My own cross-compiled version is fine, no errors there. For the record. I'm talking about the crosscompiled winetest executable from test.winehq.org and not something from the testbot. One can extract the single test from the winetest executable and that is what I did in this case. I've seen differences between winetest executable and my local crosscompiled tests in the past but never found a cause (or solution). Likewise, Octavian Voicu's machines saw no failure with the MSVC binary, but constantly produce red color on testbot. When you say "red color on testbot" you mean 'red' on test.winehq.org? -- Cheers, Paul.
Does testbot's MingW miscompile winmm:midi tests?
Hi, on test.winehq, WinME systems always report 8 rc=MMSYSERR_INVALPARAM errors. However, when running a MSVC compiled binary (as found in testbot job #4990), no such error occurs. Paul Vriens wrote: >I only see those 8 errors with the winetest executable from >test.winehq.org. My own cross-compiled version is fine, no errors there. Likewise, Octavian Voicu's machines saw no failure with the MSVC binary, but constantly produce red color on testbot. This could - Either be a bug in testbot's MingW (compilation or includes)? What's the difference between testbot compilation and Paul Vriens'? - Some weird memory corruption affecting only WinME? - a bug in my tests? Those INVALPARAM errors happen since May. However my May-19 patch did not change the tests that since fail, so it must be a side effect of something else. 1. dwBytesRecorded is left uninitialised, which may produce random results -- if it were used. 2. dwOffset is now set to 0xDEADBEEF; previously uninitialised. Yet that does not explain why MSVC's and Paul's cross compiled binary succeed. Paul and I found a bug in the mingw includes once. Perhaps that's another instance? How to proceed from here? Jörg Höhle
