Re: linux dbgutil tinderbox stuck -> backtrace

2016-04-01 Thread Norbert Thiebaud
On Fri, Apr 1, 2016 at 8:23 AM, Stephan Bergmann wrote: > > > I don't claim Jenkins is a good infrastructure for this. (But I don't want > to start any discussion about that. Just wanted to point out that adding > timeouts to test code is the wrong solution to the underlying problem of > having

Re: linux dbgutil tinderbox stuck -> backtrace

2016-04-01 Thread Stephan Bergmann
On 04/01/2016 01:22 PM, Norbert Thiebaud wrote: On Fri, Apr 1, 2016 at 2:59 AM, Stephan Bergmann wrote: 1/ we _do_ have such global level deadlock.. but jenkins being java... these are unreliable (jenkins plugin that provide that feature even explain in details that it is unreliable)... I don'

Re: linux dbgutil tinderbox stuck -> backtrace

2016-04-01 Thread Norbert Thiebaud
On Fri, Apr 1, 2016 at 2:59 AM, Stephan Bergmann wrote: > On 03/31/2016 03:17 PM, Norbert Thiebaud wrote: >> >> On Thu, Mar 31, 2016 at 7:59 AM, Michael Stahl wrote: >>> >>> it's a pretty rare deadlock, i've hit it once and sberg too once AFAIK. > > > Ah,

Re: linux dbgutil tinderbox stuck -> backtrace

2016-04-01 Thread Michael Stahl
On 01.04.2016 09:59, Stephan Bergmann wrote: > On 03/31/2016 03:17 PM, Norbert Thiebaud wrote: >> What I really wish for is a reliable hard timeout on all these tests. > > I think a better approach would be to let the bots do containerized > builds that get automatically killed after whatever ti

Re: linux dbgutil tinderbox stuck -> backtrace

2016-04-01 Thread Stephan Bergmann
On 03/31/2016 03:17 PM, Norbert Thiebaud wrote: On Thu, Mar 31, 2016 at 7:59 AM, Michael Stahl wrote: it's a pretty rare deadlock, i've hit it once and sberg too once AFAIK. Ah, "deadlock in HSQLDB" predates

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Norbert Thiebaud
On Thu, Mar 31, 2016 at 8:43 AM, Michael Stahl 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 threa

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Michael Stahl
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

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Norbert Thiebaud
On Thu, Mar 31, 2016 at 8:23 AM, Noel Grandin wrote: > Of course, it may be simpler and safer to simply surround the relevant tests > with a brute-force-5-min-timeout-and-kill. yeah.. except the timeout value should probably be longer or smarter, or an optional parameter in gbuild invocation for

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Noel Grandin
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

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Norbert Thiebaud
On Thu, Mar 31, 2016 at 7:59 AM, Michael Stahl wrote: > > it's a pretty rare deadlock, i've hit it once and sberg too once AFAIK. The problem is that on a ci system that do 1800+ build a week rare deadlock are much more common :-) I've hit that one 3 times this month. What I really wish for is

Re: linux dbgutil tinderbox stuck -> backtrace

2016-03-31 Thread Michael Stahl
On 26.03.2016 19:35, Norbert Thiebaud wrote: > Has it has heepen from time to time recently... the ci tinderbox got > stuck in a run > > This time I was able to catch a backtrace: > Note: tehre was 78 threads!! yeah that sound abusive. > so I skipped over thread that merely were a clone of a previ