[Libreoffice-qa] Issues with 3.5.0 - ready for release ...
dag at wieers.com
Wed Feb 8 03:38:39 PST 2012
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
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
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
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]
More information about the Libreoffice-qa