I was hoping that untie %$ref in the topmost script would be the only relevant fault to explicate.
Digging down gets quite complex. dbme() doesn't do the tie itself, it merely determines a number of variable specs for the wanted kind of handle and calls an appropriate sub in the handle allocater module to supply it.
But there is something strange going on.
In the same module as dbme() is another sub metadbs() which with flag=1 returns a set of similar tied-hash-handles in a hash-of-refs for a standard set of db files, itself using dbme() for each handle in turn. The $copyfrom handle above is part of this set. When called with flag=0 right before the failing untie code above, metadbs() unties each of those handle-refs (including $copyfrom) and does not hang. And has been doing so in service to a number of topmost programs for a couple of years (apparently successfully).
use DBctrl qw(svhash);
sub dbme {
my ($dbtry, $makeyn, $hm) = @_;
#....
$duplicates = 0;
$bdbtype = 'HASH';
($dbhand, $fail) = svhash($dbtry, $hm,
$makeyn, $duplicates, $bdbtype);
#.....
return ($dbhand, $fail);
}
and then digging deeper ... (difficult paste, sorry)
sub svhash {
($db, $hm, $makedb, $duplicates, $bdbtype) = @_;
$makedb ||= 0;
$duplicates ||= '';
$bdbtype ||= 'hash';
my %h;
($dbhandx, $fail) = ("", "");
$fail = _dbfix($db, $hm);
unless ($fail) {
my $bdb = BerkeleyDB::Hash;
if (lc($bdbtype) =~ /btree/) { $bdb = BerkeleyDB::Btree;}
my $fset = DB_CREATE;
my $n = "0666";
my $dups = DB_DUP | DB_DUPSORT;
$BerkeleyDB::Error = '';
if ($duplicates) {
if ($makedb) {
tie %h, $bdb, -Filename => $db, -Flags => $fset,
+ -Mode => $n, -Property => $dups
+
+ or $fail = 1;
} else {
tie %h, $bdb, -Filename => $db, -Mode => $n, -Propert
+y => $dups or $fail = 1;
}
} else {
if ($makedb) {
tie %h, $bdb, -Filename => $db, -Flags => $fset,
+ -Mode => $n or $fail = 1;
} else {
tie %h, $bdb, -Filename => $db, -Mode => $n
+ or $fail = 1;
}
}
$fail = dbresult($fail, $BerkeleyDB::Error);
unless ($fail) {$dbhandx = \%h;}
}
return ($dbhandx, $fail);
}
|