From: Murray S. K. <ms...@se...> - 2008-02-26 19:43:31
|
2.5.0.Beta9 is now out. It's worth mentioning this in particular because in this release I changed the library and filter to support the newest SSP draft (now actually ASP). This made me think it would be a good idea to rename "UseSSPDeny" to "UseSSPDiscard" because the word "deny" was changed to "discardable" in the draft specification. Thus, upgrading to the latest Beta release may cause startup to fail if you're using the old name. |
From: Todd L. <tl...@iv...> - 2008-02-27 20:20:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Feb 26, 2008 at 11:43:24AM -0800, Murray S. Kucherawy wrote: >2.5.0.Beta9 is now out. Looks good for me on the two machines that I'm running it on. The Gentoo box built with no issues. The RedHat 8 box required a bit of massaging. You may deem it an issue not worth dealing with because of the age of RedHat 8, but on my RedHat 8 system I still have to modify the db->open() call because apparently that version of db4 uses the same argument list as db3. BTW, I _really_ like the way you broke out the db->open calls into a single file! Now I only have to touch one file instead of two. Here's what I had to do to get it to compile: - --- dkim-milter-2.5.0.Beta9.orig/dkim-filter/dkim-db.c 2008-02-18 11:21:49.000000000 -0800 +++ dkim-milter-2.5.0.Beta9/dkim-filter/dkim-db.c 2008-02-27 11:55:20.000000000 -0800 @@ -61,7 +61,11 @@ status = db_create(db, NULL, 0); if (status == 0) { - -# if DB_VERSION_MAJOR > 3 + +# if DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR == 0 + status = (*db)->open(*db, file, NULL, DB_UNKNOWN, + (perms|DB_THREAD), 0); +# elif DB_VERSION_MAJOR > 3 status = (*db)->open(*db, NULL, file, NULL, DB_UNKNOWN, (perms|DB_THREAD), 0); # else /* DB_VERSION_MAJOR > 3 */ RH80[root@lunar src]# rpm -q db4 db4-devel db4-4.0.14-14 db4-devel-4.0.14-14 Quoting from: /usr/share/doc/db4-devel-4.0.14/api_c/db_open.html #include <db.h> int DB->open(DB *db, const char *file, const char *database, DBTYPE type, u_int32_t flags, int mode); - -- Regards... Todd Since the creation of the Internet, the Earth's rotation has been fueled, primarily, by the collective spinning of English teachers in their graves. --Random IRC Quote Linux kernel 2.6.22-14-generic 12 users, load average: 0.03, 0.04, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHxcX6Y2VBGxIDMLwRApRpAJ4y+6ZjusFOjuLqgqIxtn98DpRJvACdGFk1 MBKRe66M2KVYT/zio6p1g4Q= =qeHN -----END PGP SIGNATURE----- |
From: Murray S. K. <ms...@se...> - 2008-02-27 21:11:00
|
Thanks for the patch. Can you tell (probably by perusing your db.h file) which version of libdb is present on RedHat 8? From there I can figure out if some other set of conditions would be more precise. |
From: Murray S. K. <ms...@se...> - 2008-02-27 22:27:54
|
The Beta9 code compiled against libdb v4.0.14 without difficulty, without your patch. I'd be interested in knowing what version you have, since it'd be unusual for them to make an API change in a patch-level release. |
From: Todd L. <tl...@iv...> - 2008-02-28 00:01:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Feb 27, 2008 at 01:10:35PM -0800, Murray S. Kucherawy wrote: >Thanks for the patch. Can you tell (probably by perusing your db.h file) >which version of libdb is present on RedHat 8? From there I can figure >out if some other set of conditions would be more precise. #define DB_VERSION_MAJOR 4 #define DB_VERSION_MINOR 0 #define DB_VERSION_PATCH 14 #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001)" I gotta run to catch my train, I'll follow up tomorrow with more info. It _could_ be a local configuration weirdity. I just know that I've had to do this every time I have built dkim-milter on this machine. - -- Regards... Todd Any errors in spelling, tact or fact are transmission errors --Dag Wieers Linux kernel 2.6.22-14-generic 10 users, load average: 0.08, 0.08, 0.09 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHxfnQY2VBGxIDMLwRAgbbAJ9WsvFDhLR+FkuU2XL0hl9cXCsM9ACffbHs Ctccs2/D0CGhaDWJWdpBpis= =b173 -----END PGP SIGNATURE----- |
From: Murray S. K. <ms...@se...> - 2008-02-28 00:05:24
|
On Wed, 27 Feb 2008, Todd Lyons wrote: > It _could_ be a local configuration weirdity. I just know that I've had > to do this every time I have built dkim-milter on this machine. Nope, my test was bad (wrong paths). It does croak with 4.0.14. I'll have your patch (or a variant of it) in 2.5.0. Thanks! |
From: Hirohisa Y. <um...@gm...> - 2008-02-28 00:46:42
|
Hi, At Wed, 27 Feb 2008 14:27:35 -0800 (PST), Murray S. Kucherawy wrote: > > The Beta9 code compiled against libdb v4.0.14 without difficulty, without > your patch. I'd be interested in knowing what version you have, since > it'd be unusual for them to make an API change in a patch-level release. I have installed libdb versions 3.3.11, 4.0.14, 4.1.25, 4.2.52, 4.3.29, 4.4.20, 4.5.20 and 4.6.21 side-by-side (using FreeBSD ports). I marked db40 as invalid in dkim-milter FreeBSD port, since I got build errors some time ago. With 2.5.0.Beta9, while with db3 and db42 thru db46 it builds okay, I got a build error with db4 like following : | cc -g -I. -I../../include -I/usr/local/include/db4 -I/usr/local/include/tre -I../libar/ -DQUERY_CACHE -DUSE_ARLIB -DXP_MT -c dkim-cache.c | dkim-cache.c: In function 'dkim_cache_init': | dkim-cache.c:264: error: incompatible type for argument 4 of 'cache->open' | dkim-cache.c:264: error: too many arguments to function 'cache->open' | *** Error code 1 The APIs look different between v4.0 and other versions somewhere in ```subsystem-private structures''. --- /usr/local/include/db4/db.h 2007-04-26 14:44:00.000000000 +0900 +++ /usr/local/include/db41/db.h 2007-08-12 22:09:16.000000000 +0900 <snip> @@ -54,9 +54,9 @@ * Berkeley DB version information. */ #define DB_VERSION_MAJOR 4 -#define DB_VERSION_MINOR 0 -#define DB_VERSION_PATCH 14 -#define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001)" +#define DB_VERSION_MINOR 1 +#define DB_VERSION_PATCH 25 +#define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)" /* * !!! <snip> @@ -1326,7 +1184,7 @@ int (*join) __P((DB *, DBC **, DBC **, u_int32_t)); int (*key_range) __P((DB *, DB_TXN *, DBT *, DB_KEY_RANGE *, u_int32_t)); - int (*open) __P((DB *, + int (*open) __P((DB *, DB_TXN *, const char *, const char *, DBTYPE, u_int32_t, int)); int (*put) __P((DB *, DB_TXN *, DBT *, DBT *, u_int32_t)); int (*remove) __P((DB *, const char *, const char *, u_int32_t)); <snip> -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2008-02-28 00:58:32
Attachments:
PATCH
|
Try the attached patch. It makes dkim-db.c work for me for 1.85, 3.3.11, 4.0.14, 4.1.25 and 4.6.21. I have 2.7.3 on another server but haven't treid it yet. This will appear as part of the 2.5.0.Beta10 which I'll probably post tomorrow. |
From: Hirohisa Y. <um...@gm...> - 2008-02-28 01:37:13
|
At Wed, 27 Feb 2008 16:58:30 -0800 (PST), Murray S. Kucherawy wrote: > Try the attached patch. It makes dkim-db.c work for me for 1.85, > 3.3.11, 4.0.14, 4.1.25 and 4.6.21. I have 2.7.3 on another server but > haven't treid it yet. The dkim-filter built okay here for 2.7.7, 3.3.11, 4.0.14, 4.1.25 and 4.6.21 with the patch. > This will appear as part of the 2.5.0.Beta10 which I'll probably post > tomorrow. Would you please fix libdkim with QUERY_CACHE, too? -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2008-02-28 21:11:54
Attachments:
PATCH
|
On Thu, 28 Feb 2008, Hirohisa Yamaguchi wrote: > Would you please fix libdkim with QUERY_CACHE, too? The attached patch should do it. |
From: Hirohisa Y. <um...@gm...> - 2008-02-29 00:36:35
|
At Thu, 28 Feb 2008 13:11:45 -0800 (PST), Murray S. Kucherawy wrote: > On Thu, 28 Feb 2008, Hirohisa Yamaguchi wrote: > > Would you please fix libdkim with QUERY_CACHE, too? > > The attached patch should do it. With the patch, t-test49 fails for 2.7.7, 3.3.11 and 4.0.14 | Assertion failed: (db != NULL), function dkim_cache_query, file dkim-cache.c, line 328. | *** query caching | --- empty cache | Abort trap (core dumped) | FAIL: t-test49 ;; It seems okay for 1.8.5 (builtin with FreeBSD libc), 4.1.25, ;; 4.2.52, 4.3.29, 4.4.20, 4.5.20 and 4.6.21 Regards -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2008-02-29 21:53:00
|
On Fri, 29 Feb 2008, Hirohisa Yamaguchi wrote: > With the patch, t-test49 fails for 2.7.7, 3.3.11 and 4.0.14 I didn't get an error just now with 4.0.14. I'll try 3.3.11 next. I don't have a test environment for 2.7.7 (or the source) so I can't try that one, but I think a home machine does have 2.7.3. Usually assertion failures from my code include a line number or some such. It seems the assertion failure there might've been from inside libdb. That doesn't mean it's a bug there, but it's harder to spot what libdkim might've done wrong... |
From: Murray S. K. <ms...@se...> - 2008-02-29 22:13:51
|
On Fri, 29 Feb 2008, Murray S. Kucherawy wrote: > I didn't get an error just now with 4.0.14. I'll try 3.3.11 next. > [...] No problem here for 3.3.11 either. Can you get a stack trace out of the coredump your test produced? |
From: Hirohisa Y. <um...@gm...> - 2008-03-01 02:39:19
|
At Fri, 29 Feb 2008 14:13:47 -0800 (PST), Murray S. Kucherawy wrote: > > On Fri, 29 Feb 2008, Murray S. Kucherawy wrote: > > I didn't get an error just now with 4.0.14. I'll try 3.3.11 next. > > [...] > No problem here for 3.3.11 either. Can you get a stack trace out of the > coredump your test produced? I could not reproduce my problem under FreeBSD/i386. It might be amd64 (and possibly other 64bit architecures) specific. I played with gdb(1) and found that db_open() or cache->open() in dkim_cache_init() returns 22(EINVAL) under conditions that t-test49 fails. -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2008-03-01 20:35:53
|
On Sat, 1 Mar 2008, Hirohisa Yamaguchi wrote: > I could not reproduce my problem under FreeBSD/i386. It might be amd64 > (and possibly other 64bit architecures) specific. > > I played with gdb(1) and found that db_open() or cache->open() in > dkim_cache_init() returns 22(EINVAL) under conditions that t-test49 > fails. I don't have a 64-bit system with which to test (yet). I'll make a request for one. If you can spot what parameter I'm passing that it doesn't like, let me know. |
From: Murray S. K. <ms...@se...> - 2008-03-02 00:30:24
|
On Sat, 1 Mar 2008, Murray S. Kucherawy wrote: > On Sat, 1 Mar 2008, Hirohisa Yamaguchi wrote: >> I could not reproduce my problem under FreeBSD/i386. It might be amd64 >> (and possibly other 64bit architecures) specific. >> >> I played with gdb(1) and found that db_open() or cache->open() in >> dkim_cache_init() returns 22(EINVAL) under conditions that t-test49 >> fails. > > I don't have a 64-bit system with which to test (yet). I'll make a > request for one. If you can spot what parameter I'm passing that it > doesn't like, let me know. Looks like I'll have one early next week, so I can try to get to the bottom of it before posting the release, which I'm planning to do on Friday at the latest. |
From: Murray S. K. <ms...@se...> - 2008-03-03 21:14:32
|
On Sat, 1 Mar 2008, Hirohisa Yamaguchi wrote: > I played with gdb(1) and found that db_open() or cache->open() in > dkim_cache_init() returns 22(EINVAL) under conditions that t-test49 > fails. It appears use of the DB_THREAD flag is the problem. Removing it from dkim-cache.c makes the test pass on FreeBSD/amd64. This means I should be using that API differently for threaded programs. However, since the current cache management code in libdkim does its own mutex management and is meant to cover all versions of DB (including those that didn't provide direct support for threading) I'm inclined to say this is sufficient for now. |
From: Murray S. K. <ms...@se...> - 2008-03-03 21:29:11
|
On Mon, 3 Mar 2008, Murray S. Kucherawy wrote: > It appears use of the DB_THREAD flag is the problem. Removing it from > dkim-cache.c makes the test pass on FreeBSD/amd64. In particular, that version of DB requires that opening a database with DB_THREAD must be done inside an environment that was created with the same flag. libdkim doesn't do that, which may explain the error, but the confusing thing is that this code is the same on 32-bit FreeBSD which doesn't complain at all. |
From: Murray S. K. <ms...@se...> - 2008-03-03 23:10:36
|
So finally, this (attached) is the patch to dkim-cache.c (which will be in Beta11) that fixes that unit test on 64-bit FreeBSD. It appears the versions of libdb you're testing simply assume that mutexes aren't available on 64-bit FreeBSD, so attempts to tell libdb to enable its threading support caused EINVAL to be returned. (The error they return is EINVAL with a descriptive string of "architecture lacks fast mutexes: applications cannot be threaded") I've tested this against 3.3.11 and 4.0.14 and the fix works. Essentialy I don't use the threading facilities in libdb at all and just wrap the calls in a mutex. This is undoubtedly not as fast, but probably not measurably so for now. If it is indeed shown to be a performance degradation, we may simply have to declare that some versions of DB can't be used on 64-bit FreeBSD because we'll want to use the threading faciliities in libdb, and another (more extensive) patch will be needed to make more thorough use of the DB environment stuff. |
From: Murray S. K. <ms...@se...> - 2008-03-03 23:12:36
Attachments:
PATCH
|
(Forgot to attach the patch) |
From: やまきゅう <um...@gm...> - 2008-03-05 16:51:50
|
At Mon, 3 Mar 2008 15:10:22 -0800 (PST), Murray S. Kucherawy wrote: > It appears the versions of libdb you're testing simply assume that mutexes > aren't available on 64-bit FreeBSD, so attempts to tell libdb to enable > its threading support caused EINVAL to be returned. (The error they > return is EINVAL with a descriptive string of "architecture lacks fast > mutexes: applications cannot be threaded") > I've tested this against 3.3.11 and 4.0.14 and the fix works. Essentialy > I don't use the threading facilities in libdb at all and just wrap the > calls in a mutex. This is undoubtedly not as fast, but probably not > measurably so for now. If it is indeed shown to be a performance > degradation, we may simply have to declare that some versions of DB can't > be used on 64-bit FreeBSD because we'll want to use the threading > faciliities in libdb, and another (more extensive) patch will be needed > to make more thorough use of the DB environment stuff. I understand the concept of workaround, and Beta11 loos working. -- end やまきゅう um...@gm... |