Fix intermittent failures in the LeakTracer on 5.18+, remove all workarounds

( cherry-pick of 1a77219a )

ARGH! In the end the issue turned out to be stupid-simple: when PadWalker is
called it always returns us a hashref. This hashref is traversed, with its
own address recorded as seen. Once processed, the hashref itself is GCed,
leaving a stale entry in $seen_refs.

Up until 5.18 this was not a problem, likely due to no address reuse. However
after 5.18 PadWalker is very happy to return different hashrefs under the same
address over and over again. The $seen_refs entry leads to a skip, and the
actual contents of the pad are never examined - we've seen this hash already.

ARGH!

The decisive change is the single line around PadWalker - everything else is
cleanup of workarounds for this problem.

Conflicts:
Changes

Remove warning introduced in 75a1d824 (cherry-pick of cff17b97)

Port taint-related fixes from b5ce6748, 4fb8d74c and 652d9b76

Needed to pass under the updated CI framework

Keep T::B IO open in t/52leaks.t END - other ENDs pending (esp. since 961d79db)

( cherry pick of 7617dcc4 )

Read under -w

Fix Postgres test hang with DBD::Pg 3.5.0+ (work around RT#100648)

( cherry-pick of 731c2d8b )

It is not 100% clear to me why this is happening, as the change discussed[1]
was not supposed to change behaviour outside of a transaction.

The test in question essentially does a blocking request with a timeout. The
way the default DBIC machinery works is to issue a ping() after the timeout
induced exception, in order to opossibly retry the operation IFF the link
went stale ($dbh thinks everything is in order, the RDBMS believes otherwise).

After the changes in 3.5.0 this ping() now hangs, even though the access
pattern did not change (there are no transactions involved on the handle in
question). Either way, the fix is simple: just shim-away the ping for the
duration of the test.

In general this should be resolved on a higher level by disabling retries for
the duration of the test (or maybe even disabling retries by default in the
distant feature - see RT#47005)

[1] https://rt.cpan.org/Ticket/Display.html?id=100648#txn-1438093

(distbuild) Deal with newer tags correctly

Release v0.08270

RT#87124 fixed, workaround no longer necessary

Add Firebird over ODBC TravisCI testing

Give Firebird (and Interbase) a common sqlt_type

Even though the parser/producer pair do not yet exist in SQLT, we also use this
value as the basis for the lockfile on parallel tests, hence it is important

Fix datetimes in ODBC/Firebird (merge identical code left after a870aa85e)

Rudimentary DBI/DBD MDV

Clarify parallel_installdeps design comment

The trace formatter seems to register intermittent leaks - skip on 5.18 for now

Fix undefined order sensitive test (no idea how it went undetected)

Ints bound as DBI::SQL_BIGINT on SQLite < 1.37 do not work in functions

For all the meticulous testing of 04ab4eb1, 1363f0f5 and f3b1224b I
failed to notice that functions no longer work when they encounter
numbers bound as bigint (may as well have not bound them at all).
Happened due to shortsighted testing methodology as described in the
commit msg of f3b1224b, a rudimentary MDV will be introduced in a later
commit to ensure this doesn't happen anymore.

Fix this by explicitly requirung DBD::SQLite 1.37 for bigint operations.

Examine patch under -w

Release v0.08260

We still intermittently grab a "leaked" SQLT quoter, skip explicitly

Will figure this out after 0.08260

Factor out the symtable walker, no functional changes but much reshuffling

One extra cleanup pass before asserting weakregistry is empty

Make 54taint.t actually test the DBIx::Class in lib (originally 689e22d1)

Skip annoyingly failing test on broken base.pm

Was broken in 5.19.7, fixed in 5.19.8

Yet another attempt to solve the mystery-win32-failure cpantesters report

While fa19e5d6 was a nice idea, its test was flawed. As seen in the fresh fail
http://www.cpantesters.org/cpan/report/137dfaf3-7bbc-1014-aec2-3d202b825c07
the writability test passed with flying colors, but the lock didn't open right
after that. The only explanation at this point is that the FS underlying this
particular dir can not create filenames starting with a dot <facepalm />
Alternatively it may have to do with the umask(0) call, but this seems even
more insane.

Thus (as unlikely as it seems) the culprit seems to be the name. Hopefully
changing it will be the end of this and we will smoke happily ever after...

Rewrite writiability test to be clearer and with less warnings

Skip thread tests under Devel::Cover

Counter the strictures bullshit with localised bullshit

Augment the logic from aca094b4d, add deprecation to settle the distinct drama

Details in attached IRC log

magnet#dbic-cabal_20131108.log
====
[19:01:38] <mst> using aggregates and distinct seems like it should be an error
[19:02:12] <mst> since it makes no sense to ask for "GROUP BY everything we select" and then select aggregates AFAICS
[19:03:20] <mst> so, yes, what we did before was ... wtf
[19:04:44] <ribasushi> mst: the point is *sometimes* a select in a group-by may make sense is my gut feeling, I basically wanted to "send the nonsense" along, and have the rdbms be the judge
[19:05:52] <mst> well ... what we did before was definitely completely wrong
[19:06:09] <mst> what we're doing now ... I don't want to release it without thinking it through some more, but it's certainly less wrong
[19:07:40] <mst> but I mean ... I dunno, I think group_over_selection makes sense for subquery wrapping
[19:08:04] <mst> but in the case of 'distinct => 1' I think "can't do that with an aggregate in select, pass a real group by you fucking pansy" would be pretty good too
[19:08:14] <mst> since I'm really not convinced it ever can make sense
[19:08:27] <ribasushi> mst: and I am not convinced it never makes sense
[19:08:36] <ribasushi> mst: so bubbling it up doesn't seem like a loss
[19:09:09] <mst> hmmm
[19:09:44] <ribasushi> mst: also I do not want to *entirely* discourage mysql/sqlite-centric grouppage - if a person wants to do that, they should be able to
[19:09:56] <ribasushi> hence why the explicit \'' rule
[19:10:03] <ribasushi> (that is back from 2009-ish actually)
[19:10:05] <mst> actually, looking at this
[19:10:23] <mst> the sql looks like what the user asked for
[19:10:38] <ribasushi> how so?
[19:10:59] <ribasushi> distinct is "final selection grouper" not "first selection"
[19:11:00] <mst> well, they created a resultset of
[19:11:04] <ribasushi> i.e. it is inherently lazy
[19:11:29] <ribasushi> right, it does not take effect on the current selection, didn't from before I took over
[19:11:53] <mst> SELECT year, COUNT(me.cdid) AS cnt ....
[19:11:57] <mst> and then grabbed the 'cnt' column
[19:13:06] <mst> ribasushi: ResultSet originally (0.05000) did '$attrs->{group_by} ||= $attrs->{select} if delete $attrs->{distinct};' in new()
[19:13:15] <mst> so, yes, it takes effect on the current selection
[19:13:36] <mst> so sql is correct according to the original behaviour as implemented
[19:13:36] <ribasushi> mst: but it did this in *_resolve_attrs*
[19:13:55] <ribasushi> which is after the selection is modified by RSETColumn
[19:14:15] <ribasushi> or to put it diff. - RSetColumn does not do a subquery, just like a ->search doesn't
[19:14:30] <mst> it didn't originally, it did it immediately you supplied the distinct attribute to a search
[19:14:40] <mst> anything else is a bug; fix that and we don't need this crap
[19:14:52] <ribasushi> well - when I came around it was lazified via the late resolver
[19:15:08] <ribasushi> and I had bugs reported when that behavior changed later on when I was doin prefetches
[19:15:17] <ribasushi> so this is crap in production for years
[19:15:41] <ribasushi> mst: https://github.com/dbsrgits/dbix-class/blob/master/t/search/distinct.t behaviors on non-aggregates
[19:15:55] <ribasushi> it accreted stuff obviously, the ages of tests are different
[19:17:01] <ribasushi> mst: basically this boils to "is distinct => 1 lazy or eager" and I am afraid this ship sailed around 0.07
[19:17:17] <ribasushi> "fixing" it will serve nothing but bring breakage
[19:17:48] <mst> yeah, it looks like it got broken when _resolved_attrs was factored out of new()
[19:17:53] <ribasushi> nod
[19:18:28] <ribasushi> so - if we assume "distinct is lazy" - you see why I would go the way I did with the latest fix
[19:19:22] <mst> ribasushi: distinct is lazy works fine, you just have to disallow aggregates in the select list in that case
[19:19:30] <mst> and make them do an explicit group_by for that
[19:20:31] <ribasushi> mst: aggregates via the {} syntax have been supported correctly forever - that is distinct knows to ignore them
[19:20:45] <ribasushi> mst: this test is more or less "aggregate in literal" (due to being an alias)
[19:20:47] <mst> even as far as 08000 it was straight up
[19:20:51] <ribasushi> so I can't disallow it
[19:20:56] <ribasushi> because it is... a literal
[19:20:59] <mst> $attrs->{group_by} ||= $attrs->{select} if delete $attrs->{distinct};
[19:21:11] <mst> so if we started allowing them via the {} syntax that wasn't me
[19:21:17] <ribasushi> mst: I came around 0.08010 ;)
[19:22:01] <mst> ribasushi: $attrs->{group_by} ||= $attrs->{select} if delete $attrs->{distinct};
[19:22:07] <mst> ribasushi: in 08011 which is the first release you did
[19:22:34] <ribasushi> mst: it is very possibkle that I broke it when I wasn't knowing wtf is on
[19:22:46] <mst> I think you made lazy distinct work "better"
[19:22:51] <mst> when it shouldn't've been lazy
[19:22:59] <ribasushi> mst: in any case - it's old shit, so even if I am responsible it still boils to "people depend on that"
[19:23:13] <ribasushi> mst: nod, may very well be my rookie mistake ;)
[19:23:15] <mst> sure. at this point it's "I fucked it up, then you made it worse, we'll have to deprecate it"
[19:23:19] <mst> most likely
[19:23:34] <mst> and the only question is damage control so we don't break current usages while isolating the code
[19:24:48] <ribasushi> deprecating it - I wouldn't go that far, I use distinct a lot myself because it does the group construction for me without me thinking
[19:25:01] <ribasushi> juggling selection/ordering is hard enough ;)

Check that the just-built-distdir is configure-able in usermode

Shuffle author-side M::I stuff out of the way

Zero functional changes

Logically separate statements mangled in 3054407e9

Explicitly declare static config

SQLite is not a build_requires dep anymore (trap-the-sigsegv days are gone)

Remove silly double-entry from test_requires

Adjust todo escape, use travis-provided 5.8 for one of the poisontests

Clarify is_exception(undef) behavior missed in 841efcb3

Have tests recover gracefully when File::Spec->tmpdir gives us lemons

Once and for all solves http://www.cpantesters.org/cpan/report/36d4436d-7888-1014-a278-e5322b825c07

Move hrefaddr to DBIC::_Util, give most functions a prototype

This way we can safely do e.g. ( hrefaddr $foo, $unrelated_bar )

Improve error reporting when we encounter broken exception objects

Undo parts of 935ea660e (which inadevrtently broke 153a6b38), while
keeping the entire shebang running after issuing a stern warning.

Work around older DBI (possibly other cases) of faulty tie()

View diff under -w, similar failcase: http://www.perlmonks.org/?node_id=568377

GAH! DBD::SQLite's sqlite_db_filename() is relatively new, undo 9e75be92

On the bright side, re-trapping $db_file now *SEEMS TO WORK*. What the hell?
Ripping out the dogE-crap of 9e75be92, and trying to forget all of this ever
happened...

Report correct mismatching inode in the deletion guard on fixed perls

For reference:
http://www.nntp.perl.org/group/perl.perl5.porters/2011/02/msg169414.html

Scalar::Util 1.38 seems to be fixed, revert 647da28e

Do not run the expensive test under PPerl/SppedyCGI

Need some exceptions removed in 556c4fe6 when some optdeps are missing

Massive incompatible change of ::BlockRunner internals

It was never documented as usable externally (though folks do use it, sigh)
This last set of changes settles the design for proper documentation and
opening up

Fix long standing issue with resultset growth on repeated execution (GHPR#29)

The "save the SQLA argstack" dirty solution introduced in 975b573a actually
resulted in an infinitely growing nested data structure, containing the
history of *every* reinvocation of the resultset. Scale back the problematic
part, though this is still an interim workaround. A DQ-based stack should
make this much cleaner.

Stop using precomputed SQLite testdb name, fix test-end bug in replicated.t

This was an... odd one. Originally the problem manifested as a classic
var-sub-sub closure problem, leading to $db_file being captured and tripping
a more involved testcase that is coming in a subsequent commit. However while
getting rid of the reference itself was easy, this led to the outer coderef
itself being "leaked out".

The reproducing oneliner is:

~$ perl -MScalar::Util=weaken -Mstrict -Mwarnings -e '
 sub foo {
   my $rv = sub { "wtf" }; return $rv;
 }

 my $should_be_gone;

 {
   $should_be_gone = foo();
   weaken ($should_be_gone);
 }

 warn $should_be_gone;  # why is this still defined@!%#$!$#
'

Various tools indicated that it is somehow attached to the PAD of the static
foo() sub, but I could not figure out *why* exactly this is happening, nor
how to properly list it: PadWalker's closed_over() shows nothing for foo()

Thus invoking doge on the whole shebang, and moving on. SUCH WTF, WOW!

Incientally changing things to use the current SQLite filename revealed
a bug in t/storage/replicated.t, which was never noticed as it only
resulted in annoying warnings under Win32 global destroy (test
teardown).

Add extra operations to the heavy duty leaktrace scope

Fire all so-far-collected resultsets multiple times

Do not track plain scalar refs on 5.17+ for the time being

Smoke 5.16.2 (ensure we are not affected by Encode leak) and bump latest 5.18

Stop circref TODO based on RT#82942 from failing after changes in 96577657

Now that we have the tools leak-track much more stuff when XS is there

Switch to a global symtable "classdata" visitor

This not only allows us to track anything global, not only CAG stuff
but also removes a bunch of workarounda from t/52leaks.t \o/

Even saner diagnostics (view under diff -w)

Now that we no longer store signs of "ref X was here but GCed" there is no
point in "No leaks of X" pass()es either

Stop various CLONE-registries from growing indefinitely

Rewire the leaktracer to store all refs by address, not by name

Also add better diagnostics during failure

Centralize handling of refcount in DBIC::_Util

Switch the bleadcpan test to 5.8.7

Allow devcpan tests to pass by not considering SQLA 1.99_xx

Temporary CI workaround for RT#92226

Unused import

Fix ridiculous regex anchor mistake from 66137dffe

SQLite changed their exception text again

Fix warning in t/54taint.t with explicitly unset PERL5LIB (RT#91972)

Clarify that this is not a fix but a workaround for loud users

Temporary todo list

Add .mailmap entry for my work address

Fix typo in Changes

Full depchain test on plain blead

Grumble - Module::Runtime is M::B-based, wtf Zefram

Revert 8c11c33f - the AAAA record got axed

https://github.com/CPAN-API/metacpan-web/issues/1029

Extra (passing) test case generated while investigating the cause of RT#91375

Better explanation for optional fk values in rels

Fixed typos

Extra poison - have our latest stable in PERL5LIB

Better instrument memcached test against failures like 106c81a5

Require latest SQLA (some deprecations, lots of parser fixes)

Augment 287373c2 with a more pinpointed link

fix test to use qw as (so far as I can see) originally intended

misspelling

add link explaining the format of the .mailmap file

A git based install works in one step with cpanm

Dancing around T::B 1.5 is becoming untenable, just limit it away

Also add an extra 5.12.1 clean devrel smoke

Add *clean devrel* smokes (full testing of devrels of our deps using cpanm)

Show more info about the system and show what did we end up building

Disable IPV6 access until metacpan gets their act together

(Several days to fix a *known* issue with an AAAA record, seriously?)

Run parallel_installdeps_notest() with a timeout as well

Remove 37b5ab51 test warnings on older perls

Revert parts of e1ab2f7a, the depchain got perturbed again

Latest strictures now instist on bringing in the extra deps, which can't
be installed without working configure_requires

Convert many live-only SQL test to standalone is_same_sql_bind cases

Pass the correct NAME attribute to our dummy EUMM invocation

Extra (now passing) oracle test which led to the work in 37b5ab51

Grumble - this was such a simple thing to diagnose and it took a month to
see it. The culprit was the (correctly bisected to) cleanup in d87929a4,
which failed to take into account that an empty connect() can still lead
to a healthy $dbh, given system-based authoriozation, and no attributes
being passed in.

For the curious - the difficulty to diagnose was further exacerbated by
the apparent insanity of what was being generated - a (known, existing)
method name was somehow leaking into the generated SQL. In reality when
we failed to determine the driver, we also failed to determine the SQLA
subclass, which in turn made us call a nonexisting method on $sql_maker,
but *surprise* - SQL::Abstract (the granddady of it all) defines an
AUTOLOAD. Khaaaaaaaaaaaaa....

Increase oracle xe user process limit from 40 (default) to 150

Streamline connection codepath, fix $ENV{DBI_DSN} regression from d87929a4

Break out _dbi_connect_info to always take into account $ENV{DBI_DSN} on
a case-by-case basis. This allows to centralize handling of "whose driver
is this anyway" and let more exotic configs still function properly. As a
side effect need to move the _dbi_connect_info() population earlier in the
connect_info() codepath

Also break out the DBI_DRIVER reader, and use it if possible in the
_describe_connection codepath

Additionaly refactor of _connect since there is no point passing the DSN when
we can grab it from $self (this also fixed ::Replicated's _connect() loop
never actually having worked)

Make life bearable for windows users wrt EOL

Augment 1363f0f5 for running in hell

SQLite produces extra warnings on Win32 even with an appropriate IV_SIZE

Windows fork is not only slow - it plain breaks on multiple requires :(

Stop using pseudofork on the lesser platform altogether

Separate DBIC::_ENV_::* setup from loading of the main DBIx::Class module

Better specification of the JSON::* optdeps

New Test::Kwalitee completely prevents install of Pod::POM

Just skip all tests until we get a new release