Pstack has asked for the wisdom of the Perl Monks concerning the following question:

($copyto, $fail) = dbme ($newcopy, 1); $copyto->{$k} = $copyfrom->{$k}; # #... succeeds ... # #cleanup if (tied $copyto) { untie (%$copyto); print "CLEANUP: Tied-HASH now untied\n"; } else { print "'tied()'-test on copyto FAILED\n"; if (ref($copyto) eq 'HASH') {print "copyto= $copyto\n";} eval {untie (%$copyto);}; if ($@) {print "UNTIE copyto FAILED --> $@\n";} else { print "UNTIE copyto succeeded ......\n"; } } # # OUTPUT: # .. 'tied()'-test on copyto FAILED ...... # .. copyto= HASH-REF --> HASH(0x8e02f5c) # HANGS on "eval {untie (%$copyto);};" line # NEVER RETURNS ? #

EXPLANATION:

dbme() line-1 is in another module, gets a reference to a tied-hash handle on a Berkeley DB file from yet another module, returns it to this code, and which then succeeds. The record copied line-2 appears in the underlying file. But the 'untie' needed to then close the file hangs .. I have to CTRL-C to quit?

Can anyone see what I am getting wrong?

Replies are listed 'Best First'.
Re: untie tied hash fails mysteriously
by repellent (Priest) on Sep 11, 2011 at 06:05 UTC
    Does dbme() take into consideration the untie gotcha?

    Please show us the code for dbme() so we could try to reproduce the issue.
      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); }

        Is that sub really coded without strict and returning globals?:

        sub svhash { ($db, $hm, $makedb, $duplicates, $bdbtype) = @_; $makedb ||= 0; $duplicates ||= ''; $bdbtype ||= 'hash'; my %h; ($dbhandx, $fail) = ("", ""); ##<<<<<<<<<<<<< ... return ($dbhandx, $fail); ##<<<<<<<<<<<<< }

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.