Re: linux dbgutil tinderbox stuck -> backtrace

On Thu, Mar 31, 2016 at 8:43 AM, Michael Stahl <mstahl@redhat.com> wrote:
> On 31.03.2016 15:23, Noel Grandin wrote:
> > On 2016/03/31 3:17 PM, Norbert Thiebaud wrote:
> > > What I really wish for is a reliable hard timeout on all these tests.
> >
> > Not sure how much it helps, but Java has a built-in thread deadlock detector (which may or may 
> > not fire here, since it
> > only detects deadlocks where the locks in question are all Java-level locks)
> >
> > I have code that I can contribute that runs a watchdog thread that queries the Java deadlock 
> > detector every 2 seconds
> > and kills the program when a deadlock is detected.
>
> hmm... that would help in this particular case, but generally speaking,
> this is the first and only java-only deadlock i've ever seen in a test,
> usually 2 C++ threads are involved in a deadlock.
>
> > Of course, it may be simpler and safer to simply surround the relevant tests with a 
> > brute-force-5-min-timeout-and-kill.
>
> that depends on the build configuration, if you're running the test with
> ASAN / valgrind / drmemory the timeout needs to be much longer or disabled.

we could have multiplier in gbuild for these case.

like default base timeout 10 minutes
multiplier = 1
if asan multiplier = 3  (for example)

and then the actual watchdog use base_timeout * multiplier minutes as timeout

Norbert

> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice