Hello,

On FreeBSD 4.11, I've been using BerkeleyDB 4.2 for quite a while. Then I
upgraded the database, a few days back. But a few IPC Perl processes that
actually use it (BerkeleyDB-0.30) have become unstable. I've been
ktracing, setting log-points myself, but I keep getting core dumps at
places where they access BerkeleyDB. Sporadically, but often enough.

Naturally I compiled BerkeleyDB-0.30 against the correct libraries (in
config.in).

INCLUDE = /usr/local/include/db44
LIB = /usr/local/lib # also tried /usr/local/lib/db44 directly
DBNAME = -ldb-4.4

# end of file config.in

I have done this upgrade-path for BerkeleyDB and Perl several times; from
1.85 -> 4.1 -> 4.2, and now -> 4.4.20. It has always worked well. Even now
it compiles just fine. It just isn't stable anymore. And, just to be
clear, of course I wiped the __* cache files that BerkeleyDB-0.30 uses,
after upgrading.

Upgrading to 4.5 made no difference. I even installed an entirely new Perl
(5.8.8) for the occasion. To no avail.

I really suspect it's a locking issue. My app is a socketmap daemon, for
sendmail, that does SPF queries and the like. So, concurrency is
definitely happening when processes are forking.

The one time I was actually able to log an error for a process, it said:
"Invalid locker id" when opening the BerkeleyDB environment. That in
itself may not necessarily mean anything (could just mean the env has
become corrupted in general). But the occurance of the core dumps seem
consistent with a locking issue (under heavy, concurrent load).

BerkeleyDB 0.30 (the Perl package) itself takes care of locking the shared
environment. Paul Marquess, the author of BerkeleyDB (the Perl package),
wrote me once in a Perl newsgroup:

"Apart from that you don't need to do anything -- Berkeley DB handles the
locking for you behind the scenes."

And it's certainly true for for 4.2: the 'tied' hashes can be accessed,
concurrently, between processes, even under the most stringent load.

Since an upgrade to 4.5 made no difference, I'm really thinking this is
just a matter of BerkeleyDB 0.30 (the Perl package) no longer doing the
locking properly. Or maybe there's something between BerkeleyDB 4.2 and
4.4 that has changed about the manner in which locks are done that
BerkeleyDB 0.30 is unaware of?

I wonder if this is perhaps a known issue, and if anything has any ideas
how to solve this. I'd hate to think I'm not able to upgrade my BerkeleyDB
anymore.

Thanks,

- Mark