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

[Paul Vriens]

On 09/06/2010 11:02 AM, [e-mail] 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?

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

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

[Saulius Krasuckas]

* On Fri, 10 Sep 2010, [e-mail] 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/v...
[2] https://testbot.winehq.org/JobDetails.pl?Key=5184&log_101=1#k101
[3] http://source.winehq.org/git/