-=| Niko Tyni, 26.12.2016 18:32:20 +0200 |=- > [explicitly cc'ing Damyan as the firebird3.0 maintainer; see the > backtraces below. Any ideas?]
Thanks, my comments are below. > On Mon, Dec 26, 2016 at 11:07:53AM +0100, Santiago Vila wrote: > > On Mon, Dec 26, 2016 at 02:03:25AM +0100, gregor herrmann wrote: > > > On Sun, 25 Dec 2016 20:06:46 +0100, Santiago Vila wrote: > > > > > > > The "slowness" is the inverse of the speed. My unit of measure > > > > (i.e. slowness 1) is the speed of my i3-3217U @ 1.80GHz at home, > > > > which was my first autobuilder. > > > > > > Don't know where my laptop qualifies with > > > model name : Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz > > > :) > > > > Most probably, yes. > > FWIW I've tried quite a bit locally with different VM setups but I don't > see any failures, with the underlying HW a quad-core of > > model name : Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz > > However, I had temporary access to a host where the original failure > happened: t/embed-90-dbinfo.t and others get a SIGSEGV at cleanup phase, > after passing all the tests. > > Observations: > > - it needs PERL_DL_NONLAZY=1 to happen > - the gcc optimization level of DBD::Firebird XS parts doesn't affect it > - strace makes it go away, and IIRC so does valgrind > - there are always three threads active when it crashes; the crashing > thread backtrace is totally unhelpful but the main thread seems to be > the Firebird server unloading plugin modules or something like that the third thread is something running a timer. It could be that the timer-driven code tries to access something that is being dlclose'd. This all reminds be of #846025 (random crashes during test-like activity when building firebird3.0). Santiago, can you try building firebird3.0_3.0.1.32609.ds4-10 a few times on a similar mix of slow/fast builders? If it fails the same, I think that would indicate that the problem is in firebird3.0 and not in libdbd-firebird-perl. I think upstream would find helpful if a core file can be provided along the build log. (3.0.1.32609.ds4-10 is required sinde -11 makes the crashes in the "tests" non-fatal) Another cause can be related to http://tracker.firebirdsql.org/browse/CORE-4508 -- fb_shutdown() apparently needs to be called before libfbembed is unloaded (dlclose'd?). DBD::FirebirdEmbedded doesn't call fb_shutdown at all. I'll try to find time to provide a patch for DBD::Firebird incorporating fb_shutdown in the embedded variant that is used during tests. No guarantees on a timeline, sadly. -=| Santiago Vila, 26.12.2016 17:46:52 +0100 |=- > On Mon, Dec 26, 2016 at 06:32:20PM +0200, Niko Tyni wrote: > > > FWIW I've tried quite a bit locally with different VM setups but I don't > > see any failures, with the underlying HW a quad-core of > > > > model name : Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz > > > > However, I had temporary access to a host where the original failure > > happened: t/embed-90-dbinfo.t and others get a SIGSEGV at cleanup phase, > > after passing all the tests. > > For the record, and just in case it matters, the host where we were > able to reproduce this more or less easily was a single-CPU virtual > machine inside a quad-core of: > > model name: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Hmm, My laptop has Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz and my office PC has an quad-core AMD@3.4GHz, but still I wasn't able to reproduce this. Ghosts everywhere :) -- Damyan
signature.asc
Description: Digital signature
