Nifty new valgrind report script. New error in oleaut32. Call for volunteer(s).

[Dan Kegel]

I finally got tired of doing "history | grep diff" etc, and
partially automated the daily valgrind run; the resulting
script is at http://kegel.com/wine/valgrind/valgrind-daily.sh

The results are now in directories named like
http://kegel.com/wine/valgrind/logs-2007-12-06/
A summary of the new problems compared to last run are in files named like
http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt
And next to each individual result, there is a diff with the previous run, e.g.
http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat.txt
http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.tx...

To look at what changed since yesterday, start by looking at the day's
summary file.
In it, there's one line per test, followed by the changes in that
test's results, if any.
Lines that start with + indicate new problems (boo);
lines that start with - indicate old problems that are now gone (yay!)
Nearby lines that are identical except for one starting with + and one
starting with -
indicate a problem that moved, so ignore those.

For example, in today's summary,
http://kegel.com/wine/valgrind/logs-2007-12-06-summary.txt
the first test with changes is in hlink:

diff -u logs-2007-12-05/vg-hlink_hlink.txt logs-2007-12-06/vg-hlink_hlink.txt
- Syscall param write(buf) points to uninitialised byte(s)

That means the hlink test has one fewer error.  Yay!

The next test with changes is

diff -u logs-2007-12-05/vg-ole32_moniker.txt
logs-2007-12-06/vg-ole32_moniker.txt
+ Syscall param write(buf) points to uninitialised byte(s)
- Syscall param write(buf) points to uninitialised byte(s)
- Conditional jump or move depends on uninitialised value(s)

The 'Syscall' error just moved, so that's not really a change.
The 'Conditional' error went away, yay!

The next test with changes is

diff -u logs-2007-12-05/vg-oleaut32_varformat.txt
logs-2007-12-06/vg-oleaut32_varformat.txt
+ Invalid read of size 2

That's a + with no matching -, so it's a new error, boo!
Let's see if it's a real error, or just crap in the log.  The
first thing to check is the diff of that test's results with the last run:
http://kegel.com/wine/valgrind/logs-2007-12-06/vg-oleaut32_varformat-diff.tx...
It shows a fairly convincing new error:

+ Invalid read of size 2
+    at  VarFormatFromTokens (varformat.c:1888)
+    by  VarFormat (varformat.c:2096)
+    by  func_varformat (varformat.c:317)
+    by  run_test (test.h:387)
+    by  main (test.h:436)
+  Address 0x7F00AB01 is 15 bytes before a block of size 8 alloc'd
+    at  RtlAllocateHeap (heap.c:1225)
+    by  SysAllocStringByteLen (oleaut.c:357)
+    by  VariantCopy (variant.c:722)
+    by  VariantChangeTypeEx (variant.c:992)
+    by  VarFormatFromTokens (varformat.c:1884)
+    by  VarFormat (varformat.c:2096)
+    by  func_varformat (varformat.c:317)
+    by  run_test (test.h:387)
+    by  main (test.h:436)

Now, sometimes tests are flaky, and errors
just happen to come and go, so this doesn't mean
for sure it's a new error.  But looking back a
few days, I don't see it before.  So it's probably
a new error.  Let's see, who's been submitting changes
to oleaut32 lately?    Only change in git since the last run seems to be
http://www.winehq.org/pipermail/wine-cvs/2007-December/038491.html
It's not clear how that patch could have caused the error offhand,
but it's worth emailing the author and asking him to check,
so I've cc'd him.

And that's the only new error in the whole run.

It's worth watching for new errors and alerting the authors,
since the change is fresh in their mind, they'll probably
be able to fix it quickly.   Egg in the face is a dish best served warm.

I'll try to keep running this script daily, but it'd be nice if
somebody else took over (and possibly even increased
the automation; I still have to do git pull, run the script, and
upload by hand.)
It doesn't help that valgrind only works well on some machines,
but hey, what's life without challenges.
- Dan