[Libreoffice-qa] minutes of ESC call ...

[Michael Stahl]

On 28.07.2016 18:19, Markus Mohrhard wrote:
> 
> 
> On Thu, Jul 28, 2016 at 5:18 PM, Michael Meeks
> <michael.meeks at collabora.com <mailto:michael.meeks at collabora.com>> wrote:
> 
> 
>     * Crashtest update (Caolan)
>         + 1 import failure, 7 export failures, coverity pending
>         + discovered there was a timeout, throwing an assert after 2 minutes
>           an issue on the crash-testing box, but not when tested..
>         + marketing numbers of 0.00 for coverity correct as of last
>     testing cf. 5.2 branch
>         + database documents being round-tripped (Michael S)
>            + had a tendency to deadlock - 10% of them.
>            + ended up being killed by the python script: didn't result
>     in a crashlog.
>            + only get an entry in the crashlog if we get a dispose
>     exception.
>            + have a fix for that; to introduce in the database document the
>              solar mutex for locking
>                + another potential gift that will give and give.
>            + crash test now runs without deadlocking
>            -> can we fix the python script - to report hangs ? (Michael)
>                + some where writer has an infinite layout loop (Michael S)
>                + should these be reported in crash-testing ? not sure.
> 
> 
> The script was reporting the files it could not open and the files that
> took too long. Keep in mind that this not only covers deadlocks and
> therefore it was nearly impossible to get anything useful from the
> results. It limits all tests for a file (so all the import and then
> reexport to different formats to 3 minutes). In theory we could increase
> the limit and enable reporting again to reduce the number of false
> positives but that will also increase the runtime of the crash testing
> significantly.

also i'm getting a lot (> 300) of time-outs when running the script on a
--enable-dbgutil build; i think there are several benign reasons:

* some of the files are very large and template-heavy C++ code like STL
and MDDS relies a lot on inlining so no wonder a build without
optimization is taking some time

* some of the files have HTTP links to images that cause network timeouts

if we could somehow detect that the soffice.bin is still spinning the
CPU we might avoid the first non-problem but not the second.