Please test RE24 for 2.4.19 preparation. Thanks!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Quanah Gibson-Mount wrote:
Please test RE24 for 2.4.19 preparation. Thanks!
All tests succeeded on FreeBSD/amd64 8.0.
Cheers, - -- Xin LI delphij@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve!
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24 for 2.4.19 preparation. Thanks!
opensuse-11.1-x86_64 OK but I have got the feeling that the tests run rather slow, i.e. test039 which takes more than 25 sec for 1000 binds, in previous versions this was done within 11 - 13 sec AFAIR. This is a single core athlon64 and 4GB RAM, top showed up to 80% CPU usage.
-Dieter
All good on Fedora 32/64.
----- "Quanah Gibson-Mount" quanah@zimbra.com wrote:
Please test RE24 for 2.4.19 preparation. Thanks!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
On Tue, 29 Sep 2009, Quanah Gibson-Mount wrote:
Please test RE24 for 2.4.19 preparation. Thanks!
Looks like mt_mutex might have been hit out of order? Under test058:
current thread: t@5 [1] lwp_mutex_lock(0x1005d3578, 0x7fffffff7e712d70, 0x0, 0x1, 0x0, 0x7fffffff75ffe6d9), at 0x7fffffff7e717e6c [2] mutex_lock_kernel(0x1005d3578, 0x0, 0x0, 0x10533c, 0x7fffffff7e713b38, 0x0), at 0x7fffffff7e712e10 [3] mutex_lock_internal(0x0, 0x10, 0x7fffffff7e601000, 0x1002542b0, 0x100cb07a2, 0x100cb0851), at 0x7fffffff7e713e58 =>[4] ldap_pvt_thread_mutex_lock(mutex = 0x1005d3578), line 296 in "thr_posix.c" [5] syncprov_op_mod(op = 0x7fffffff75fff400, rs = 0x7fffffff75ffeec8), line 1965 in "syncprov.c" [6] overlay_op_walk(op = 0x7fffffff75fff400, rs = 0x7fffffff75ffeec8, which = op_modify, oi = 0x100719820, on = 0x10071b490), line 659 in "backover.c" [7] over_op_func(op = 0x7fffffff75fff400, rs = 0x7fffffff75ffeec8, which = op_modify), line 721 in "backover.c" [8] over_op_modify(op = 0x7fffffff75fff400, rs = 0x7fffffff75ffeec8), line 760 in "backover.c" [9] syncrepl_updateCookie(si = 0x1007188d0, op = 0x7fffffff75fff400, pdn = 0x1007172e0, syncCookie = 0x7fffffff75fff178), line 3059 in "syncrepl.c" [10] do_syncrep2(op = 0x7fffffff75fff400, si = 0x1007188d0), line 1177 in "syncrepl.c" [11] do_syncrepl(ctx = 0x7fffffff75fffc20, arg = 0x1005548f0), line 1358 in "syncrepl.c" [12] connection_read_thread(ctx = 0x7fffffff75fffc20, argv = 0x1e), line 1261 in "connection.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x1005365e0), line 685 in "tpool.c"
(dbx) thread -blockedby t@5 Thread t@5 is blocked by: 0x00000001005d3578 (0x1005d3578): usync_? mutex(locked) Lock is unowned
and the slapd is deadlocked.
On Wed, 30 Sep 2009, Aaron Richton wrote:
(dbx) thread -blockedby t@5 Thread t@5 is blocked by: 0x00000001005d3578 (0x1005d3578): usync_? mutex(locked) Lock is unowned
and the slapd is deadlocked.
Hmm...actually, this is with 2.4.18. But I don't know if there were changes on point since then?
--On Thursday, October 01, 2009 10:00 AM -0400 Aaron Richton richton@nbcs.rutgers.edu wrote:
On Wed, 30 Sep 2009, Aaron Richton wrote:
(dbx) thread -blockedby t@5 Thread t@5 is blocked by: 0x00000001005d3578 (0x1005d3578): usync_? mutex(locked) Lock is unowned
and the slapd is deadlocked.
Hmm...actually, this is with 2.4.18. But I don't know if there were changes on point since then?
Not that I'm aware of.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Failed test056 under Fedora 12...under valgrind, which reported a clean run.
--- ldif.flt 2009-10-01 18:12:09.000000000 -0400 +++ ldapsearch.flt 2009-10-01 18:12:09.000000000 -0400 @@ -1,3 +1,18 @@ +dn: cn=Connection 0,cn=Connections,cn=Monitor +structuralObjectClass: monitorConnection +monitorConnectionProtocol: 3 +monitorConnectionOpsReceived: 3 +monitorConnectionOpsExecuting: 1 +monitorConnectionOpsPending: 0 +monitorConnectionOpsCompleted: 2 +monitorConnectionGet: 3 +monitorConnectionRead: 3 +monitorConnectionWrite: 0 +monitorConnectionMask: xC +monitorConnectionListener: ldap://localhost:9011/ +monitorConnectionLocalAddress: IP=LOCAL:9011 +entryDN: cn=Connection 0,cn=Connections,cn=Monitor + dn: cn=Connection 1,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection monitorConnectionProtocol: 3
On Thu, 1 Oct 2009, Aaron Richton wrote:
Hmm...actually, this is with 2.4.18. But I don't know if there were changes on point since then?
Got the same thing with RE24 checkout from yesterday.
current thread: t@8 [1] lwp_mutex_lock(0x1005d3b88, 0x7fffffff7e712d70, 0x0, 0x1, 0x0, 0x7fffffff73bfe6d9), at 0x7fffffff7e717e6c [2] mutex_lock_kernel(0x1005d3b88, 0x0, 0x0, 0x10533c, 0x7fffffff7e713b38, 0x0), at 0x7fffffff7e712e10 [3] mutex_lock_internal(0x0, 0x10, 0x7fffffff7e601c00, 0x100254608, 0x101160b72, 0x101160c21), at 0x7fffffff7e713e58 =>[4] ldap_pvt_thread_mutex_lock(mutex = 0x1005d3b88), line 296 in "thr_posix.c" [5] syncprov_op_mod(op = 0x7fffffff73bff400, rs = 0x7fffffff73bfeec8), line 1965 in "syncprov.c" [6] overlay_op_walk(op = 0x7fffffff73bff400, rs = 0x7fffffff73bfeec8, which = op_modify, oi = 0x100719ed0, on = 0x10071bb40), line 659 in "backover.c" [7] over_op_func(op = 0x7fffffff73bff400, rs = 0x7fffffff73bfeec8, which = op_modify), line 721 in "backover.c" [8] over_op_modify(op = 0x7fffffff73bff400, rs = 0x7fffffff73bfeec8), line 760 in "backover.c" [9] syncrepl_updateCookie(si = 0x100718e60, op = 0x7fffffff73bff400, pdn = 0x100717870, syncCookie = 0x7fffffff73bff178), line 3059 in "syncrepl.c" [10] do_syncrep2(op = 0x7fffffff73bff400, si = 0x100718e60), line 1177 in "syncrepl.c" [11] do_syncrepl(ctx = 0x7fffffff73bffc20, arg = 0x1007190d0), line 1358 in "syncrepl.c" [12] connection_read_thread(ctx = 0x7fffffff73bffc20, argv = 0x1c), line 1261 in "connection.c" [13] ldap_int_thread_pool_wrapper(xpool = 0x100536b70), line 685 in "tpool.c"
Aaron Richton wrote:
On Thu, 1 Oct 2009, Aaron Richton wrote:
Hmm...actually, this is with 2.4.18. But I don't know if there were changes on point since then?
Got the same thing with RE24 checkout from yesterday.
I have also managed the same, after about 800 runs of test058.. Currently testing a possible fix..
Rein
-
Aaron Richton -
Dieter Kluenter -
Gavin Henry -
Quanah Gibson-Mount -
Rein Tollevik -
Xin LI