Skip Menu |

This queue is for tickets about the BerkeleyDB CPAN distribution.

Report information
The Basics
Id: 37377
Status: resolved
Priority: 0/
Queue: BerkeleyDB

People
Owner: Nobody in particular
Requestors: mark [...] hindley.org.uk
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Reference counting across forks
Date: Thu, 3 Jul 2008 13:07:07 +0100
To: bug-BerkeleyDB [...] rt.cpan.org
From: Mark Hindley <mark [...] hindley.org.uk>
Paul, I have been trying to track down the cause of lots of "environment reference count went negative" messages in the BerkeleyDB log. I think reference counting across forks is broken. This is using 0.34, libdb4.6, all from Debian sid. I have isolated a test case which is below and triggers the error message for me. The issue seems to be that both processes try to close the environment after the fork, even though one does not use the tied hash. Obviously Berkeley DB handles shouldn't be shared across a fork, but in this case they aren't. I tried to untie %db and $dbh in the child, but the message still persists. Mark Test case: #!/usr/bin/perl use strict; use warnings; use BerkeleyDB; my $env = new BerkeleyDB::Env -Home => '/tmp', -Flags => DB_CREATE | DB_INIT_MPOOL | DB_INIT_CDB, -ErrFile => *STDERR, -ErrPrefix => "[$$]" or die $!; my $dbh = tie my %db, 'BerkeleyDB::Hash', -Filename => '/tmp/test.db', -Flags => DB_CREATE, -Env => $env or die $!; my $pid= fork; if ($pid) { # use %db here print "$$: Parent\n"; } else { undef $dbh; untie %db; print "$$: Child\n"; }
Show quoted text
> Paul,
Hi Mark Show quoted text
> I have been trying to track down the cause of lots of "environment > reference count went negative" messages in the BerkeleyDB log. > > I think reference counting across forks is broken.
That's because it isn't supported. Show quoted text
> This is using 0.34, > libdb4.6, all from Debian sid. > > I have isolated a test case which is below and triggers the error
message Show quoted text
> for me. The issue seems to be that both processes try to close the > environment after the fork, even though one does not use the tied
hash. Show quoted text
> > Obviously Berkeley DB handles shouldn't be shared across a fork, but
in Show quoted text
> this case they aren't.
But they are. You open a database in the parent process, then do a fork. At this stage both the parent & clind processses have an open database handle. My code is designed to gracefully close a dabase connection when it goes out of scope or when the process terminates. In your case that means that both the parent and the chile will close the same database connection. In the code you supplied the child will close it explicitly, while the parent will close it behind the scenes when the process terminates. cheers Paul
Subject: Re: [rt.cpan.org #37377] Reference counting across forks
Date: Tue, 8 Jul 2008 09:44:07 +0100
To: Paul Marquess via RT <bug-BerkeleyDB [...] rt.cpan.org>
From: Mark Hindley <mark [...] hindley.org.uk>
On Sun, Jul 06, 2008 at 05:27:19PM -0400, Paul Marquess via RT wrote: Show quoted text
> > Obviously Berkeley DB handles shouldn't be shared across a fork, but
> in
> > this case they aren't.
> > But they are. You open a database in the parent process, then do a > fork. At this stage both the parent & clind processses have an open > database handle. My code is designed to gracefully close a dabase > connection when it goes out of scope or when the process terminates. In > your case that means that both the parent and the chile will close the > same database connection. In the code you supplied the child will close > it explicitly, while the parent will close it behind the scenes when > the process terminates.
OK, I had misunderstood here. I had thought that the BerkeleyDB limitation on forks was the same as the parent library -- ie you shouldn't access the same handle from both sides of a fork, not that you shouldn't fork whilst holding a handle. FWIW, I have changed my application and now use the database methods directly rather than though the tie interface, as well as opening handles after the fork. It now seems rock solid. Feel free to close this. Thanks Mark