Perl 5.40 errors: DBI dr handle cleared whilst still active during global destruction

[dlangille]

After moving from Perl 5.38 to Perl 5.40, errors such as this started to appear.

EDIT: The problem is also reproducible on Perl 5.42

DBI db handle 0x190cb2d3bb40 has 1 uncleared child handles during global destruction.
    dbih_clearcom (dbh 0x190cb2d3bb40, com 0x190cb23a8980, imp DBD::Pg::db):
       FLAGS 0x580111: COMSET Warn PrintError PrintWarn 
       PARENT DBI::dr=HASH(0x190cb2d3cd20)
       KIDS 1 (0 Active)

With the help of Perl/perl5#23306 I was able to create a small test script, which comes close to producing this.

[16:22 dev-ingress01 dvl ~/scripts] % perl perl5-issue-23306                
DONE
we are done
DBI dr handle 0x2e63aee41ae0 cleared whilst still active during global destruction.
    dbih_clearcom (drh 0x2e63aee41ae0, com 0x2e63ae4b12c0, imp DBD::Pg::dr):
       FLAGS 0x100215: COMSET Active Warn PrintWarn AutoCommit 
       PARENT undef
       KIDS 0 (1 Active)
[16:26 dev-ingress01 dvl ~/scripts] % 

The script is:

#!/usr/bin/env perl

use strict;
use warnings;
use DBI;



my $dbh = DBI->connect("dbi:Pg:dbname=freshports.dev;host=pg03.example.org", "redacted", 'redaacted');

print "DONE\n";
exit 0;

sub sub1 {
    $dbh = "";
}

END {
#    $dbh->disconnect if $dbh;
#    $dbh = undef;
    print "we are done\n";
}

If either of the lines in END are uncommented, the error does not occur.

In my code, the problem is not reproducible. It seems to happen sometimes. For example, on three hosts running the same code and processing the same input, the error might appear on one, but not the other two. Sometimes on two, but not the third. It is not consistent and is rarely reproducible.

[dlangille]

Is this fixable by the user? Am I missing an undef or a disconnect?

Advice is welcomed here. How would you fix this?

[gedge]

For the record, I am seeing similar and intermittent errors recently, ⚠ but not for pg instead for sqlite ⚠
likely related to an upgrade to perl 5.40 (but not sure)...

DBI db handle 0x121fc2681708 has 1 uncleared child handles, <GEN1> chunk 53 during global destruction.
    dbih_clearcom (dbh 0x121fc2681708, com 0x121fc24fc400, imp DBD::SQLite::db):
       FLAGS 0x180391: COMSET Warn RaiseError PrintError PrintWarn AutoCommit
       PARENT DBI::dr=HASH(0x121fc2782f78)
       KIDS 1 (0 Active)

[cron2]

I see this with DBD::mysql, so this is not tied to a particular database.

In my case it went away by adding an

END { $my_dbh->disconnect(); $my_dbh = undef; }

block to my database.pm module that does all the DB stuff (so I have a workaround), but still it would be good to see this fixed ;-)

[dlangille]

That patch does clear the messages for me. I'll try implementing that in my dev environment and see if it works there too.

[dlangille]

That patch does clear the messages for me. I'll try implementing that in my dev environment and see if it works there too.

The patch fails to fix my dev code. The script in question is (some comments removed, but the script is as shown, without the various modules/packages it uses)

[17:24 dvl-ingress01 dvl ~/scripts] % cat load_xml_into_db.pl
#!/usr/local/bin/perl -w

use strict;

use FreshPorts::database;
use FreshPorts::observer_commits;
use FreshPorts::xml_munge;

my $Munger = FreshPorts::XML_Munge->new();

print "about to process\n";
my $ErrorFound = $Munger->process();

my $source = $Munger->getSource();

print "That commit is of Type: '$source'\n";

print "EOF\n";

my $dbh = FreshPorts::Database::GetDBHandle();
if ($dbh->{Active}) {

	if ($source eq 'subversion') {

		print "invoking XML_Munge_svn because this is a subversion commit\n";
		die('we do not do subversion any more');

	} elsif ($source eq 'git') {

		print "invoking XML_Munge_git because this is a git commit\n";
		use FreshPorts::xml_munge_git;
		$Munger = FreshPorts::XML_Munge_git->new($dbh);

	} else {
	    $dbh->disconnect();
	    die("Unkmown source: '$source'\n");
	}

	my $ObserverCommits = FreshPorts::ObserverCommits->new($dbh);

	$Munger->add_observer($ObserverCommits);

	print "about to process\n";
	$ErrorFound = $Munger->process();

	print " now is the commit:\n";

	$Munger->notify_observers($FreshPorts::Messages::TransactionCommitted);

	$dbh->disconnect();
	print "EOF\n";
}


END {
   $dbh->disconnect();
   undef $dbh;
}

[dlangille]

I want to point out: In my code, the problem is not reproducible. It happens. I run the code again, it does not repeat. The sample code is always repeatable.

Also, three website instances running the same code over the same data: 1 might produce the problem output, the other two won't. Sometimes two websites will error on the same input data. Never have all three.

[dlangille]

I wanted to point out:

Does it matter that the FreeBSD ports build seems to mention pthread in just:

ldflags ='-pthread -Wl,-E  -fstack-protector-strong -L/usr/local/lib'

but the non-reproducing builds have it in:

+    libs=-lpthread -ldl -lm -lcrypt -lutil -lc
+    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc

instead?

Originally posted by @richardleach in #23306

[jkeenan]

Please see the analysis from @iabyn in Perl/perl5#23306 (comment). If this analysis is correct, then the problem falls on the FreeBSD ports side, not the Perl or DBI side. But stay tuned for further details!

[dlangille]

From Perl/perl5#23306 (comment):

Adding CFLAGS+= -DNO_POSIX_2008_LOCALE to /usr/ports/databases/p5-DBI/Makefile and rebuilding the FreeBSD package clears the test case for me.