Bug#847288: libdbd-firebird-perl: FTBFS randomly (failing tests)

[Damyan Ivanov]

-=| 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 at 3.4GHz, but still I wasn't able to 
reproduce this. Ghosts everywhere :)


-- Damyan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20161227/9c746836/attachment.sig>