Re: Trouble with Berkeley DB version 4.4.20?
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Trouble with Berkeley DB version 4.4.20?
-Original Message- From: Alex Zbyslaw [mailto:[EMAIL PROTECTED] Sent: maandag 2 oktober 2006 12:50 To: Mark Cc: 'FreeBSD-Questions Questions' Subject: Re: Trouble with Berkeley DB version 4.4.20? Thanks for answering, again. 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 behav- ior. 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 :-( For all the difference it made. :) 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. I know. In fact, I have one mini-Perl installed, with a DB_File compiled against BerkeleyDB 1.85, for that precise reason (a Perl process that shares the db with DRAC). 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 sleepy- cat, sets up some configure args, and has one small patch to dist/con- figure which changes -avoid-version into -version-info 0:0:0 in a cou- ple of places. Already did that; I got impatient. :) The changes to the Makefile are minor, and I got 4.5.20 to compile and install just great. 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 noth- ing 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. 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 the 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). But the occurance of the core dumps are 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: 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. - Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Trouble with Berkeley DB version 4.4.20?
Hello, I realize this is probably not the most flashy issue, but, if possible, I would really like an answer to this question. I compiled BerkeleyDB 4.4.20 with the following 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. If someone out there has an idea, I'd really like to know. Thanks, - Mark -Original Message- From: Mark [mailto:[EMAIL PROTECTED] Sent: vrijdag 29 september 2006 20:29 To: 'FreeBSD-Questions Questions' Subject: Trouble with Berkeley DB version 4.4.20? Hello, Am I the only person having trouble with Berkeley DB version 4.4.20? I've been using 4.2 for quite a while. Then I upgraded, a few days back. But a Perl process that actually uses it (BerkeleyDB-0.30) has become unstable. I've been ktracing it, and setting log-points myself, but it keeps core dumping at places where it accesses BerkeleyDB. Sporadically, but often enough. Naturally I compiled BerkeleyDB-0.30 against the correct libraries (in config.in). And it seems more or less ok, but not always. Finally, this morning, I just did a full restore from an earlier date; db44 is not working out for me, obviously. I'm not sure whether it's Berkeley DB version 4.4.20 or BerkeleyDB-0.30, or a combination of the two; but I wonder if someone else has had trou- ble with it, too? Sometimes I got a weird lock error notice; but other- wise it remains a mystery. - Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Trouble with Berkeley DB version 4.4.20?
Mark wrote: Hello, I realize this is probably not the most flashy issue, but, if possible, I would really like an answer to this question. I compiled BerkeleyDB 4.4.20 with the following 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. 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 answering because no-one active is doing anything with these particular package 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. I use 4.2 with p5-BerkeleyDB and no problems for me, but I do nothing complicated - really just pretend it's 1.85 without bugs! What about 4.3? If you don't need the functionality of 4.4 then downgrade back to 4.2 and keep an eye on the 4.4 and p5-BerkeleyDB ports, and try again in a few months. Other than that, try google as your problem may not have anything to do with FreeBSD, or try asking the p5-BerkeleyDB author - maybe they have other feedback like yours. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Trouble with Berkeley DB version 4.4.20?
-Original Message- From: Alex Zbyslaw [mailto:[EMAIL PROTECTED] Sent: zaterdag 30 september 2006 20:14 To: Mark Cc: 'FreeBSD-Questions Questions' Subject: Re: Trouble with Berkeley DB version 4.4.20? 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. I use 4.2 with p5-BerkeleyDB and no problems for me, but I do nothing complicated - really just pretend it's 1.85 without bugs! My BerkeleyDB 4.2 with Perl is rock-stable, too. Never a glitch of any kind. If you don't need the functionality of 4.4 then downgrade back to 4.2 and keep an eye on the 4.4 and p5-BerkeleyDB ports, and try again in a few months. I think I'll do that. I believe BerkeleyDB 4.5 has just been released already. I'll wait for it to appear in the ports. I do not actually need the functionality of 4.4. Like you, I just use 4.2 as 1.85 without the bugs. :) Upgrading just seemed like the thing to do. If you look at the Sleepycat bug-list, it seems they fixed a whole lot of them since 4.2; but I cannot say I ever really ran into one. So, I'll wait for 4.5. Not much I can do. Should have been a pretty straightforward upgrade; but it isn't. And analyzing a Perl core dump without symbolic information is pretty useless too. Besides, from my own debug markers I set, it does not core dump in the same place each time. So, it's just that: unstable. Thanks, - Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Trouble with Berkeley DB version 4.4.20?
Hello, Am I the only person having trouble with Berkeley DB version 4.4.20? I've been using 4.2 for quite a while. Then I upgraded, a few days back. But a Perl process that actually uses it (BerkeleyDB-0.30) has become unstable. I've been ktracing it, and setting log-points myself, but it keeps core dumping at places where it accesses BerkeleyDB. Sporadically, but often enough. Naturally I compiled BerkeleyDB-0.30 against the correct libraries (in config.in). And it seems more or less ok, but not always. Finally, this morning, I just did a full restore from an earlier date; db44 is not working out for me, obviously. I'm not sure whether it's Berkeley DB version 4.4.20 or BerkeleyDB-0.30, or a combination of the two; but I wonder if someone else has had trouble with it, too? Sometimes I got a weird lock error notice; but otherwise it remains a mystery. - Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Trouble with Berkeley DB version 4.4.20?
Hello, Am I the only person having trouble with Berkeley DB version 4.4.20? I've been using 4.2 for quite a while. Then I upgraded, a few days back. But a Perl process that actually uses it (BerkeleyDB-0.30) has become unstable. I've been ktracing it, and setting log-points myself, but it keeps core dumping at places where it accesses BerkeleyDB. Sporadically, but often enough. Naturally I compiled BerkeleyDB-0.30 against the correct libraries (in config.in). And it seems more or less ok, but not always. Finally, this morning, I just did a full restore from an earlier date; db44 is not working out for me, obviously. I'm not sure whether it's Berkeley DB version 4.4.20 or BerkeleyDB-0.30, or a combination of the two; but I wonder if someone else has had trouble with it, too? Sometimes I got a weird lock error notice; but otherwise it remains a mystery. - Mark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
