[Libreoffice-qa] Issues with 3.5.0 - ready for release ...

[Dag Wieers]

On Wed, 8 Feb 2012, Markus Mohrhard wrote:

> 2012/2/8 Caolán McNamara <caolanm at redhat.com>:
>> On Tue, 2012-02-07 at 22:05 +0100, Markus Mohrhard wrote:
>>> But keep in mind that this is nothing that will be fast. I needed
>>> around one week to check a bit more than 4000 files
>>
>> My times are dramatically faster than this for .doc files in writer at
>> least. I can load 4000 .doc files *under valgrind* overnight in about 10
>> hours. So apparently mileage varies quite a bit depending on hardware
>> and file format and debugging level.
>
> That only works if you have no crashs or looping documents. Especially
> looping is a big problem in calc.
>
> Then if we want to be fast using a debug/dbgutil build is the wrong
> way but then we loose the advantages of gcc's safe iterators.
>
> So I think 4000 known good documents can be easily tested in one day
> or even faster with a "decent" machine but taking 4000 random
> documents from bugzilla needs some manual interaction and therefore
> will need more time.
> As mentionend in the last mail, I think we could speed that up by
> copying the test code and the makefile several times and run the test
> in parallel. That way we could use more cores and would be more
> reliable against crashs. ( we should of course not commit this stuff
> then)

I would investigate in what cloudooo is doing, they already monitor the 
process and detect a runaway/memory-leaked process, or intervene when a 
conversion is spending more time than we would expect.

If we simply implement his logic in a small python tool and make it work 
on a directory of documents, we could run this command every night using 
the latest snapshot and record/log any debug output (in parallel if need 
be).

And if we use the same (growing) set of documents we also test for 
regressions by having a directory of files that never failed, and a 
directory with files that have failed, and have the tool move the files 
around.

And in the same time the robustness of the UNO python bindings is tests 
;-)

PS I would add cloudooo logic to unoconv, but I prefer to keep workarounds
    out of unoconv, as I prefer such errors to be reported rather than hide
    them from users.

-- 
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]