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

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 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

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"