linux dbgutil tinderbox stuck -> backtrace

Norbert Thiebaud nthiebaud at
Fri Apr 1 00:33:52 UTC 2016

On Thu, Mar 31, 2016 at 8:43 AM, Michael Stahl <mstahl at> 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


> _______________________________________________
> LibreOffice mailing list
> LibreOffice at

More information about the LibreOffice mailing list