Trouble with Berkeley DB version 4.4.20?

[Alex Zbyslaw]

Mark wrote:

>>>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.
>>>
>>>If someone out there has an idea, I'd really like to know.
>>>      
>>>
>>I don't have any good answers for you, sorry. Probably no-one is answer-
>>ing because no-one active is doing anything with these particular pack-
>>age versions.
>>
>>But, there is a port of BerkeleyDB (databases/p5-BerkeleyDB) which would
>>save you from having to mess around configuring config.in yourself. Just
>>set something like WITH_BDB_VER=44 (or 42 or...) in pkgtools.conf (for
>>portupgrade) or make.conf or on the command line. The port doesn't seem
>>to do any local patches so I wouldn't expect it to work any better for
>>you, unless you have been doing something wrong.
>>    
>>
>
>Thanks for answering. Really appreciate it.
>
>I actually already tried p5-BerkeleyDB too. Had high hopes for it. It took
>a good 10 minutes or so to compile a new gcc, 3.2.23, first; but after
>that, everything went well. Except that it shows the same behavior.
>Compile goes fine; "make tests" too. But my app core dumps every, say,
>30 times it accesses BerkeleyDB.
>  
>
Not sure why p5-BerkeleyDB thinks it needs a specific gcc, though 3.2.23 
is the version I have anyway (FreeBSD 5.4) so I didn't know to warn you :-(

If you want to pursue further here are some suggestions that I might try:

    1) Make sure you are not doing anything non-standard like using a 
different thread library, or different CFLAGS.  You never know...

    2) Try using a different underlying database type if you can.  E.g. 
if you use hash, then try btree or vice versa

I don't know what your apps do, but make sure for example, that if you 
can have multiple instances which can write to the db at the same time 
that your are locking correctly.  In 1.85 compatibility usage that means 
locking a separate file with e.g. flock and *not* locking the database 
file itself which doesn't work right.

Waiting for 4.5 is an option, but I would worry that whatever change in 
4.4 is making your app crash might also bite in 4.5.  I could find 
nothing on google about perl+4.4 core dumping so I would harbour a  
suspicion that it is something about the way you are using BerkeleyDB 
which is causing the trouble.   I could be wrong of course :-)

--Alex

PS I know there isn't a port yet, but you could just try compiling 4.5 
from the sleepycat sources.  The port for 4.4 doesn't look like it does 
anything sophisticated: just applies the latest patches from sleepycat, 
sets up some configure args, and has one small patch to dist/configure 
which changes -avoid-version into -version-info 0:0:0 in a couple of places.

PPS If I have a chance at some point to try my software with 4.4 I will 
let you know how I get on.  Regrettably, I don't have time right now to 
try it.