Skip Menu |

This queue is for tickets about the DBIx-Class CPAN distribution.

Report information
The Basics
Id: 104429
Status: resolved
Priority: 0/
Queue: DBIx-Class

People
Owner: Nobody in particular
Requestors: w.phillip.moore [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: 0.082821



Subject: Test suite failure: 52leaks.t
I'm getting a single test to fail for all platform/compile combinations I've tried (CentOS 5/6 both 32/64 bit builds, perl5.16 through perl5.20). Otherwise, everything else passes just fine. The attached log file has the output of the 00describe-environment test, as well as the verbose output of the failing test. I'm guessing this on's relatively minor, but a test suite failure aborts all my automated installs, so there's that....
Subject: DBIx-Class-0.082820-52leaks.txt

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #104429] Test suite failure: 52leaks.t
Date: Thu, 14 May 2015 15:48:48 +0200
To: bug-DBIx-Class [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
On 05/14/2015 03:29 PM, Phillip Moore via RT wrote: Show quoted text
> Thu May 14 09:29:05 2015: Request 104429 was acted upon. > Transaction: Ticket created by WPMOORE > Queue: DBIx-Class > Subject: Test suite failure: 52leaks.t > Broken in: 0.082820 > Severity: Normal > Owner: Nobody > Requestors: w.phillip.moore@gmail.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104429 > > > > I'm getting a single test to fail for all platform/compile combinations I've tried (CentOS 5/6 both 32/64 bit builds, perl5.16 through perl5.20). Otherwise, everything else passes just fine. > > The attached log file has the output of the 00describe-environment test, as well as the verbose output of the failing test. > > I'm guessing this on's relatively minor, but a test suite failure aborts all my automated installs, so there's that....
Known issue, the failure is harmless. It is not yet fixed because I am retooling the CI to be able to detect this kind of condition properly. The issue is extremely rare, and is due to your system having a non-existent (or non-functioning) Variable::Magic (which B::Hooks::EndOfScope was supposed to pull in as long as you have a compiler). Sorry for the trouble, I am working on the CI retool as we speak...
Subject: Re: [rt.cpan.org #104429] Test suite failure: 52leaks.t
Date: Thu, 14 May 2015 10:15:38 -0400
To: bug-DBIx-Class [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
Actually, this looks like an issue with how my B-Scope-EndOfScope is built. It is NOT pulling in the Variable::Magic dependency, since it's defined as a "recommends" in the META.json. This might be a bug in my own build system, and if that's the case, this bug report is misdirected. I'll followup once I've done some more digging. Thanks for the info on Variable::Magic -- that's the clue I never would have found on my own. On Thu, May 14, 2015 at 9:49 AM, Peter Rabbitson via RT < bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=104429 > > > On 05/14/2015 03:29 PM, Phillip Moore via RT wrote:
> > Thu May 14 09:29:05 2015: Request 104429 was acted upon. > > Transaction: Ticket created by WPMOORE > > Queue: DBIx-Class > > Subject: Test suite failure: 52leaks.t > > Broken in: 0.082820 > > Severity: Normal > > Owner: Nobody > > Requestors: w.phillip.moore@gmail.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=104429 > > > > > > > I'm getting a single test to fail for all platform/compile combinations
> I've tried (CentOS 5/6 both 32/64 bit builds, perl5.16 through perl5.20). > Otherwise, everything else passes just fine.
> > > > The attached log file has the output of the 00describe-environment test,
> as well as the verbose output of the failing test.
> > > > I'm guessing this on's relatively minor, but a test suite failure aborts
> all my automated installs, so there's that.... > > Known issue, the failure is harmless. > > It is not yet fixed because I am retooling the CI to be able to detect > this kind of condition properly. > > The issue is extremely rare, and is due to your system having a > non-existent (or non-functioning) Variable::Magic (which > B::Hooks::EndOfScope was supposed to pull in as long as you have a > compiler). > > Sorry for the trouble, I am working on the CI retool as we speak... > >
On Thu May 14 15:29:05 2015, WPMOORE wrote: Show quoted text
> I'm getting a single test to fail for all platform/compile > combinations I've tried (CentOS 5/6 both 32/64 bit builds, perl5.16 > through perl5.20). Otherwise, everything else passes just fine.
This has finally been adressed by https://github.com/dbsrgits/dbix-class/commit/e9d552de#diff-6512506a6e6af2d802755bffacd45d8a Apologies for the delay, I wanted to make sure the CI tooling is adequate to catch this and future errors. I am hoping for a stable release of this in ~2 weeks.
Subject: Re: [rt.cpan.org #104429] Test suite failure: 52leaks.t
Date: Wed, 20 May 2015 07:19:58 -0400
To: bug-DBIx-Class [...] rt.cpan.org
From: Phillip Moore <w.phillip.moore [...] gmail.com>
I got 0.820820 to pass it's test suite, but it required forcing B-Hooks-EndOfScope to compile with Variable-Magic. This is a case where it seems you have a subtle dependency upon Variable-Magic, simply because if Variable-Magic isn't installed, then B-Hooks-EndOfScope won't work for you. I doubt anyone else will see this problem, since B-H-EofS actually declares V::M as a required dependency dynamically (in MYMETA.json, generated by Makefile.PL), and my build system got fooled by the fact that the static definition (the META.json in the distro) is a recommends. What happens is that even if the required dependency is NOT installed, then B-H-EofS actually still builds, but it builds the pure-perl version, not the XS version. That is, the code itself actually treats V::M as a recommends, since it will compile fine without it. It's the difference in behavior between the PP and XS versions that triggers the failed test suite in YOUR code. If it's PP, you get the error. If it's XS, it passes. IM!HO, this is a bug in the way B-H-EofS is built, but no one will ever listen to a bug report about it -- if you declare something as required, and it isn't present, then your module should NOT build, test and install without error. This is what I get for creating my own perl build infrastructure -- I get to stumble into weird edge conditions like this. Now I check for and handle the case where a single dependency might be declared as BOTH recommends and required. And that was more than you ever cared to know about this, probably.... On Wed, May 20, 2015 at 6:52 AM, Peter Rabbitson via RT < bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=104429 > > > On Thu May 14 15:29:05 2015, WPMOORE wrote:
> > I'm getting a single test to fail for all platform/compile > > combinations I've tried (CentOS 5/6 both 32/64 bit builds, perl5.16 > > through perl5.20). Otherwise, everything else passes just fine.
> > This has finally been adressed by > https://github.com/dbsrgits/dbix-class/commit/e9d552de#diff-6512506a6e6af2d802755bffacd45d8a > > Apologies for the delay, I wanted to make sure the CI tooling is adequate > to catch this and future errors. > > I am hoping for a stable release of this in ~2 weeks. >
On Wed May 20 13:20:22 2015, WPMOORE wrote: Show quoted text
> I got 0.820820 to pass it's test suite, but it required forcing > B-Hooks-EndOfScope to compile with Variable-Magic. > > This is a case where it seems you have a subtle dependency upon > Variable-Magic, simply because if Variable-Magic isn't installed, then > B-Hooks-EndOfScope won't work for you.
This is not the case. Please read the explanation carefully: https://github.com/dbsrgits/dbix-class/blob/current/blead/t/52leaks.t#L449-L455 This triggers because the test in question is hardly doing regular stuff: https://github.com/dbsrgits/dbix-class/blob/current/blead/t/52leaks.t#L65-L87 Show quoted text
> I doubt anyone else will see > this > problem, since B-H-EofS actually declares V::M as a required > dependency > dynamically (in MYMETA.json, generated by Makefile.PL), and my build > system > got fooled by the fact that the static definition (the META.json in > the > distro) is a recommends.
We have been over this - META.* is (at best) a a minimal set of what you may need. There are many modules that do this "extra deps at config time" dance to give you more "ooompf". Among the deps of DBIC alone you have (this is off the top of my head, there are certainly others, and the list changes all the time): https://metacpan.org/source/HAARG/Devel-GlobalDestruction-0.13/Makefile.PL#L40 https://metacpan.org/source/DOY/Package-Stash-0.37/Makefile.PL#L87 https://metacpan.org/source/RIBASUSHI/Class-Accessor-Grouped-0.10012/Makefile.PL#L24 https://metacpan.org/source/ETHER/B-Hooks-EndOfScope-0.15/Makefile.PL#L56 Show quoted text
> What happens is that even if the required > dependency is NOT installed, then B-H-EofS actually still builds, but > it > builds the pure-perl version, not the XS version. That is, the > code > itself actually treats V::M as a recommends, since it will compile > fine > without it. It's the difference in behavior between the PP and XS > versions > that triggers the failed test suite in YOUR code. If it's PP, you > get > the error. If it's XS, it passes.
Correct, and only on PP with 5.10+. B::Hooks::EndOfScope has 3(!) modes of operation: via Variable::Magic via https://metacpan.org/source/ETHER/B-Hooks-EndOfScope-0.15/lib/B/Hooks/EndOfScope/PP/HintHash.pm or via https://metacpan.org/source/ETHER/B-Hooks-EndOfScope-0.15/lib/B/Hooks/EndOfScope/PP/FieldHash.pm Show quoted text
> IM!HO, this is a bug in the way B-H-EofS is built, but no one will > ever > listen to a bug report about it -- if you declare something as > required, > and it isn't present, then your module should NOT build, test and > install > without error.
Given I (personally) am the one who wrote the 3-prong system - I am listening. However I am not sure how I can provide the idempotence of "works in any case", while at the same keeping things static. I am also a little confused by your claim "should NOT build, test and install without error". The module is an abstraction. It has a test suite. This test suite is fulfilled by differently operating machinery depending on circumstances. Isn't this the very definition of library...? :) Show quoted text
> This is what I get for creating my own perl build infrastructure -- I > get > to stumble into weird edge conditions like this. Now I check for and > handle the case where a single dependency might be declared as BOTH > recommends and required.
See the other links higher up - often times recommends() is *not* declared at all. It is the configure-time decision that matters in the end. Bottom line (as I've told you previously) is that unless dynamic_config is explicitly set to 0, you can not fully trust META.* which is nothing more than advisory. It is as simple as that.
Now on CPAN, and tested to not recur[1]. Sorry for the delay. [1] https://github.com/dbsrgits/dbix-class/commit/59effb9d#diff-154ebf33dba569eefb7c2ac72bf9d74bR48