WineTest log size

[Francois Gouget]

TL;DR: The todo below generates more than 90 KB of test report data. It 
       would be really nice to fix it.
storage32.c:3401: todo_wine ok(failed == expect_failed, "open with byte %x locked, mode %x %s but should %s\n",

Some of my WineTest reports went over the 1.5MB limit again and while 
the issue was not what I initially thought, I wrote a script (see 
attachment) to slice and dice them to figure out who contributes what.

Lines   Bytes  Category
 1530  114848  9 traces generating >= 5120 bytes each
 1842  106511  33 traces generating 2048 - 5119 bytes each
 7020  358649  2221 traces generating < 2048 bytes each

2071  180266  9 todos generating >= 5120 bytes each
  842   67746  20 todos generating 2048 - 5119 bytes each
 4622  329705  2894 todos generating < 2048 bytes each

170   15372  Test failed
 2787  144801  Others
--------------------
20884 1317898  Total

Traces are easy to deal with so I've sent some patches. We'll see how it 
goes.

The todos are much harder as they require fixing Wine. Still, if we 
manage to fix the top 9 we'll save around 180 KB. The next 66 KB require 
fixing 20 more todos, which is still somewhat plausible, but it gets 
hopeless after that.

The 'Others' category corresponds to the report header with the 
dlls list, and to the per test summaries.

So we're looking at minimum report size of 813 KB, but in practice we're 
unlikely to get below 1 MB.

Here are the top 20 traces and todos:

$ dupcount --traces *.report | head -n 20
Lines  Chars  Match
  296  31777  font.c:3711:      # Patch pending
  339  20378  protocol.c:765:   # Patch pending
  143  14471  ddrawmodes.c:369: # Patch pending
  171   9576  loader.c:1414:    # Patch pending
  226   9121  clipboard.c:154:  # Patch pending
   90   9050  ddrawmodes.c:340: # Patch pending
  105   7875  istream.c:486:    # Patch pending
   82   7444  win.c:82:
   78   5156  button.c:588:
   85   5015  shlview.c:59:
  145   4785  locale.c:3296:    # Patch pending
  131   4716  protocol.c:583:   # Patch pending
   54   4539  http.c:428:
   56   4300  metafile.c:1736:
   75   4050  locale.c:3215:    # Patch pending
  145   3936  locale.c:3190:    # Patch pending
   57   3846  msg.c:11475:
   98   3626  clipboard.c:132:  # Patch pending
   48   3574  metafile.c:504:

$ dupcount -e '^[^:]*:[0-9]*: Test marked todo*:' *.report | head -n 20
Lines  Chars  Match
  902  93357  storage32.c:3401: Test marked todo:
  296  21312  sock.c:2741: Test marked todo:
  256  18176  virtual.c:3350: Test marked todo:
  256  14592  ebrowser.c:1742: Test marked todo:
  110   8405  shlexec.c:1472: Test marked todo:
   22   6530  shlexec.c:1462: Test marked todo:
   74   6395  font.c:3789: Test marked todo:
   92   6074  propvariant.c:169: Test marked todo:
   63   5425  font.c:3781: Test marked todo:
   63   4788  file.c:4209: Test marked todo:
   63   4714  file.c:4207: Test marked todo:
   29   4569  dib.c:1322: Test marked todo:
   64   4504  graphics.c:3686: Test marked todo:
   64   4432  graphics.c:3657: Test marked todo:
   64   4432  graphics.c:3674: Test marked todo:
   54   4042  saxreader.c:2393: Test marked todo:
   42   3982  qcap.c:337: Test marked todo:
   38   3834  saxreader.c:2489: Test marked todo:
   25   3764  batch.c:312: Test marked todo:

[Vincent Povirk]

On Fri, May 8, 2015 at 10:47 AM, Francois Gouget  wrote:
> TL;DR: The todo below generates more than 90 KB of test report data. It
>        would be really nice to fix it.
> storage32.c:3401: todo_wine ok(failed == expect_failed, "open with byte %x locked, mode %x %s but should %s\n",

Woohoo! I'm number one!

Although arguably that's 3 todos each with their own entry in a
struct, I'm guessing one of them would still be on top anyway. Most of
it is probably the readonly exclusive mode, which I'm guessing will
actually fail to open a file if any byte in the file is locked at all.

It shouldn't be hard to fix, but I cannot guess the reason behind
native's behavior, and it didn't seem like an important detail to get
right.