From @obra

--

From @obra

Message RFC822:
MIME-Version: 1.0 (Apple Message framework v1084)
List-Post: mailto:perl5-porters@perl.org
X-Spam-Status: No, score=-7.512 tagged_above=-99.9 required=10
tests=[AWL=-0.611, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001]
autolearn=unavailable
X-Mailer: Apple Mail (2.1084)
List-Help: mailto:perl5-porters-help@perl.org
X-Spam-Flag: NO
X-List-Archive: http://nntp.perl.org/group/perl.perl5.porters/170840
X-Old-Spam-Check-BY: la.mx.develooper.com
Message-ID: 384BB191-6AAC-47FE-92E7-0162F765C180@activestate.com
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Spam-Score: -7.512
Received: from hipster.bestpractical.com (hipster.bestpractical.com
[136.248.126.165]) by fsck.bestpractical.com (Postfix) with ESMTPS id
61CF11080DF for jesse+perl.org@fsck.bestpractical.com; Mon,
11 Apr 2011 17:14:41 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by
hipster.bestpractical.com (Postfix) with ESMTP id 421932418E1 for
jesse+perl.org@fsck.bestpractical.com; Mon, 11 Apr 2011 17:14:41 -0400
(EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost
(hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with
ESMTP id kE6RgCHLFbvR for jesse+perl.org@fsck.bestpractical.com; Mon,
11 Apr 2011 17:14:41 -0400 (EDT)
Received: from x1.develooper.com (x1.develooper.com [207.171.7.70]) by
hipster.bestpractical.com (Postfix) with SMTP id D6CF02418E0 for
jesse+perl.org@fsck.com; Mon, 11 Apr 2011 17:14:40 -0400 (EDT)
Received: (qmail 19529 invoked by uid 225); 11 Apr 2011 21:14:40 -0000
Received: (qmail 19524 invoked by alias); 11 Apr 2011 21:14:39 -0000
Received: from x6.develooper.com (HELO x6.develooper.com) (207.171.7.86)
by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 11 Apr 2011
14:14:38 -0700
Received: from lists-nntp.develooper.com (localhost.localdomain
[127.0.0.1]) by x6.develooper.com (Postfix) with SMTP id 2801A17A92 for
jesse@perl.org; Mon, 11 Apr 2011 14:14:29 -0700 (PDT)
Received: (qmail 17086 invoked by uid 514); 11 Apr 2011 21:14:23 -0000
Received: (qmail 17074 invoked from network); 11 Apr 2011 21:14:23 -0000
Delivered-To: jesse+perl.org@fsck.bestpractical.com
Delivered-To: jesse@perl.org
Delivered-To: mailing list perl5-porters@perl.org
Delivered-To: perl5-porters@perl.org
Subject: panic: magic_killbackrefs (flags=ff) during global destruction
Return-Path: perl5-porters-return-170840-jesse=perl.org@perl.org
X-Original-To: jesse+perl.org@fsck.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
X-Old-Spam-Status: No, hits=-4.0 required=8.0 tests=PERLBUG_CONF,SPF_PASS,T_RP_MATCHES_RCVD
Date: Mon, 11 Apr 2011 23:14:14 +0200
X-Spam-Level:
Mailing-List: contact perl5-porters-help@perl.org; run by ezmlm
Precedence: bulk
To: Perl5 Porters Mailing List perl5-porters@perl.org
List-ID: <perl5-porters.perl.org>
Content-Transfer-Encoding: quoted-printable
List-Unsubscribe: mailto:perl5-porters-unsubscribe@perl.org
From: Gisle Aas gisle@activestate.com
X-RT-Original-Encoding: us-ascii
Content-Length: 980

DBD-Oracle fails its t/14threads.t tests with perl-5.14-tobe where it did n=
ot fail with perl-5.12. I've reported[1] this failure to the DBD-Oracle ma=
intainers. I just wanted to ask if any of the perl5-porters know somethin=
g that might explain this failure.

The failing test[2] runs like this:

$ perl -Mblib t/14threads.t=20
1..19
ok 1 - session 0 created
ok 2 - session 1 matches previous session
ok 3 - session 2 matches previous session
ok 4 - session 3 matches previous session
ok 5 - session 4 matches previous session
ok 6 - one imp_data in pool
ok 7 - thread gets two separate sessions
ok 8 - get same session after free
panic: magic_killbackrefs (flags=3Dff) during global destruction.

$ perl -V
Summary of my perl5 (revision 5 version 14 subversion 0) configuration:
Commit id: 7d779b2
[...]

Regards,
Gisle

[1] https://rt.cpan.org/Ticket/Display.html?id=3D67315
[2] http://cpansearch.perl.org/src/PYTHIAN/DBD-Oracle-1.28/t/14threads.t

From @obra

DBD-Oracle fails its t/14threads.t tests with perl-5.14-tobe where it did not fail with perl-5.12. I've reported[1] this failure to the DBD-Oracle maintainers. I just wanted to ask if any of the perl5-porters know something that might explain this failure.

The failing test[2] runs like this​:

$ perl -Mblib t/14threads.t
1..19
ok 1 - session 0 created
ok 2 - session 1 matches previous session
ok 3 - session 2 matches previous session
ok 4 - session 3 matches previous session
ok 5 - session 4 matches previous session
ok 6 - one imp_data in pool
ok 7 - thread gets two separate sessions
ok 8 - get same session after free
panic​: magic_killbackrefs (flags=ff) during global destruction.

$ perl -V
Summary of my perl5 (revision 5 version 14 subversion 0) configuration​:
Commit id​: 7d779b2
[...]

Regards,
Gisle

[1] https://rt.cpan.org/Ticket/Display.html?id=67315
[2] http​://cpansearch.perl.org/src/PYTHIAN/DBD-Oracle-1.28/t/14threads.t

From @obra

I opened a ticket for this. It's [perl #88330] - and it's nwo a 5.14
blocker.

On Tue, Apr 12, 2011 at 12​:28​:35AM +0200, Gisle Aas wrote​:

On Apr 11, 2011, at 23​:41 , Leon Timmermans wrote​:

On Mon, Apr 11, 2011 at 11​:14 PM, Gisle Aas <gisle@​activestate.com> wrote​:

DBD-Oracle fails its t/14threads.t tests with perl-5.14-tobe where it did not fail with perl-5.12. I've reported[1] this failure to the DBD-Oracle maintainers. I just wanted to ask if any of the perl5-porters know something that might explain this failure.

There was a change to some details how global destruction works in
commit 4155e4f (and maybe more), it causes some objects to be
destroyed that previously weren't. My first guess would be that that's
involved, though there must be something else going on too.

I tried to compile a perl @​ 4155e4f^ and installed DBI/DBD-Oracle with it. It still fails in in the same way. I guess I should try to 'git bisect' this. Setting things up for each test is a bit slow, so it might take a while to get a result.

--Gisle

--

From @iabyn

On Tue, Apr 12, 2011 at 03​:36​:34AM -0400, Jesse Vincent wrote​:

I opened a ticket for this. It's [perl #88330] - and it's nwo a 5.14
blocker.

I've reduced the test case to​:

  #!/usr/bin/perl
  $| = 1;

  use threads;
  use DBI;

  my $c = DBI->connect( $ENV{ORACLE_DSN}, $ENV{ORACLE_USERID},
  '', { dbi_imp_data => $imp_data } )
  or die;
  my $imp = $c->take_imp_data;

  $c = DBI->connect( $ENV{ORACLE_DSN}, $ENV{ORACLE_USERID},
  '', { dbi_imp_data => $imp_data } )
  or die;

  $imp = $c->take_imp_data;

where running it with
  ORACLE_DSN=DBI​:Oracle​://hostname/SID
  ORACLE_USERID=user/pass
gives

panic​: magic_killbackrefs (flags=ff) during global destruction.

Tomorrow I'll try to work out whether it's my/perl's fault,
or DBI's, or DBD​::Oracle's.

(Actually, its probably Oracle's fault. My experience over the last 5
years is that its *always* Oracle's fault. God how I hate Oracle​: both
the company and the software. I've wasted months of my life trying keep
Oracle RAC databases working. Whoever wrote that pile of shite should be
taken out and shot. Repeatedly. And then shot some more. Rule #1 of RAC​:
any attempt to use RAC will decrease, not increase your system's
availability. Rule #2 of RAC​: don't believe the output of any status
commands. Rule #3 of RAC​: pray, pray, that none of the nodes in your
cluster ever dies; it's almost impossible to remove the dead server from
the cluster. Rule #5 of RAC​: if your network's default gateway
temporarily goes offline (e.g. a brief reboot after a 2am firmware
upgrade), then all the nodes in your RAC cluster will go offline, and will
have to be manually restarted (they don't automatically come back up when
the router comes back up). Lastly, did I mention that I hate Oracle and
all its works?

Now, where have my dried frog pills got to ...?)

--
Music lesson​: a symbiotic relationship whereby a pupil's embellishments
concerning the amount of practice performed since the last lesson are
rewarded with embellishments from the teacher concerning the pupil's
progress over the corresponding period.

The RT System itself - Status changed from 'new' to 'open'

From @iabyn

On Wed, Apr 13, 2011 at 01​:30​:50AM +0100, Dave Mitchell wrote​:

I've reduced the test case to​:

Now fixed with the commit shown below.

Code to produce the panic can be reduced to the following core-only​:

  use Scalar​::Util qw(weaken);
  my $r = [];
  Internals​::SvREFCNT(@​$r, 9);
  my $r1 = $r;
  weaken($r1);
  my $r2 = $r;
  weaken($r2);

Basically, DBI (or DBD​::Oracle) is partly at fault, because it is
leaking an HV that has backref magic. Because the HV's refcount is
artificially high, it survives multiple passes of Perl_sv_clean_all,
while the AV containing the backref magic gets cleaned up on the second
pass.

The "fix" in perl is simply to accept that this can happen and not panic
in global cleanup.

Note that 5648c0a didn't actually
break anything; it just reorganised the code a bit so that the panic
was no longer inadvertently skipped.

I'll also mention this issue on the DBD​::Oracle ticket, as I suspect that
the HV leaking is a bug.

commit da0c0b2
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Apr 13 14​:35​:09 2011 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Wed Apr 13 14​:49​:09 2011 +0100

  handle freed backref array in global cleanup
 
  [perl #88330]
 
  If a thinggy is heavily leaked, so that it takes multiple passes through
  Perl_sv_clean_all to get its refcount to zero, then if it has weak refs to
  it, its backref array may get freed before it. We already set the
  refcount of the array to 2 to preserve it across one pass of
  Perl_sv_clean_all, but I can't think of a way of protecting it more
  generally (short of using a private array structure rather than an AV).
 
  In the past, this caused a scary assertion failure.
 
  Now instead, just skip if we're in global cleanup and the array is freed.
  This isn't ideal, but its reasonably robust, as we don't reuse freed SVs
  once in global cleanup (so the freed AV hangs around to be identified as
  such).

--
Monto Blanco... scorchio!

@iabyn - Status changed from 'open' to 'resolved'