linux dbgutil tinderbox stuck -> backtrace

Norbert Thiebaud 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

Norbert

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


More information about the LibreOffice mailing list