2009/7/30 Phil Pennock <exim-users@???>:
>> I run dbm test, just like in doc/dbm.discuss.txt and there is loop in scan:
>
> So this is a FreeBSD bug, which needs to be filed against FreeBSD. Exim
> uses the system DB libraries and assumes that they're sane.
>
> You can work around it by installing gdbm and setting USE_GDBM in the
> Exim Local/Makefile; you should perhaps file a Ports bug to do this, if
> it looks like the FreeBSD base bug isn't going to be fixed any time
> soon.
>
> See section 4.3 of The Exim Specification (doc/spec.txt), which tells
> you to do something like:
> USE_GDBM=yes
> DBMLIB=-lgdbm
>
> If Exim is having problems as a result of a system bug, but is the only
> real user of the library, then Exim will be how it shows up on the
> system, but there's nothing that can be done by Exim to fix this except
> say "don't use the db library on that system, it's buggy, build Exim to
> use something else".
I found whats wrong, but not sure who is wrong: exim or FreeBSD.
Exim use "first? DB_FIRST : DB_NEXT" in db v2, v3, but in v1 it use
"R_FIRST : 0", but R_FIRST is not 0:
/usr/include/db.h:#define R_FIRST 3 /* seq */
FreeBSD r190495 introduced this loop, but only if used incorrectly.
So it looks like both should be fixed.
Patch was obtained from OpenBSD (and/or NetBSD) so I think same problem here.
This patch fix problem for me:
--- src/dbstuff.h.orig 2007-08-29 14:02:22.000000000 +0000
+++ src/dbstuff.h 2009-07-30 05:19:01.914981107 +0000
@@ -331,7 +331,7 @@
/* EXIM_DBSCAN - returns TRUE if data is returned, FALSE at end */
#define EXIM_DBSCAN(db, key, data, first, cursor) \
- ((db)->seq(db, &key, &data, (first? R_FIRST : 0)) == 0)
+ ((db)->seq(db, &key, &data, (first? R_FIRST : R_NEXT)) == 0)
/* EXIM_DBDELETE_CURSOR - terminate scanning operation (null). Make it
refer to cursor, to keep picky compilers happy. */
--
Artis Caune
Everything should be made as simple as possible, but not simpler.
