linux dbgutil tinderbox stuck -> backtrace
nthiebaud at gmail.com
Fri Apr 1 00:33:52 UTC 2016
On Thu, Mar 31, 2016 at 8:43 AM, Michael Stahl <mstahl at 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
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
More information about the LibreOffice