Hello,
I compiled 2.4.28 and I'm trying to recreate the issue with that version but I've run into two other issues that are causing slapd to crash in the meantime. I compiled with the following options:
./configure --enable-ldap --enable-meta --prefix="/opt/local/openldap-2.4.28" --enable-dynlist --enable-memberof --enable-rwm --enable-mdb=no
The first issue is that slapd has crashed twice with a SIGBUS and dumped a core file. I haven't been able to regularly reproduce it but both times it happened on the initial query after a bind. The stack of the thread where that signal originates wasn't identical both times but the two instances look similar:
----------------- lwp# 6 / thread# 6 -------------------- fedd446c _malloc_unlocked (28, 0, 1a40cb8, 1646c0, 0, 0) + 22c fedd4224 malloc (28, 1, 940a8, 59550, fee68288, fee709b0) + 4c 001646c0 ber_memalloc_x (28, 0, 0, 0, 0, 2fcfc8) + 58 00059550 ch_malloc (28, 427390, 0, fbfff428, 8000, 4551c8) + 8 00047910 ???????? (7864d4, 7866e4, 0, 0, 0, 2fcfc8) 00047b20 attrs_dup (7866e4, 427390, 0, fbfff428, 8000, 63) + 48 0004a980 entry_dup2 (4273d4, 427384, 0, 0, 0, 2fcfc8) + ac 0011f1d4 ???????? (fffffff6, fbfffcb8, 2932d0, fbfff428, 8000, 63) 0011f938 ???????? (1a3cfe0, fbfffcb8, 0, 0, 1, 0) 000a2fe4 ???????? (8000, fbfffcb8, 1b5b298, 2627c8, 8000, a2f70) 0004e978 ???????? (1a3cfe0, fbfffcb8, 2, 41a10, ffffffff, ffffffff) 00050d88 slap_send_search_entry (0, fbfffcb8, 1b5b298, 2627c8, 262750, 1ee000) + 3d4 00041de8 fe_op_search (1a3cfe0, fbfffcb8, 2, 41a10, 1, 0) + 3d8 000a39cc overlay_op_walk (8000, fbfffcb8, 8000, 1ee5f8, 8000, 200) + c8 000a3ae4 ???????? (1a3cfe0, fbfffcb8, 2, 0, 2b9d88, 1ee6f0) 00041528 do_search (1a3cfe0, fbfffcb8, fee6cbc0, fe020c00, 40f98, fbfffa38) + 590 0003f8e4 ???????? (fbfffe08, 1a3cfe0, fee6cbc0, fe020c00, 2fcfe8, 0) 00040270 ???????? (0, 20, fee6cbc0, fe020c00, 268328, 0) 0013ca30 ???????? (268318, fc000000, 0, 0, 13c8d4, 1) fee40368 _lwp_start (0, 0, 0, 0, 0, 0)
----------------- lwp# 5 / thread# 5 -------------------- fedd446c _malloc_unlocked (800, 1, 420780, fedd4224, 0, 0) + 22c fedd416c _smalloc (18, 0, 9415c, 16cbc8, fffffff9, fee6fa48) + 4c fedd4224 malloc (17, 1, 940a8, 16cf38, fee68288, fee709b0) + 4c 0016cbc8 ber_memalloc_x (17, 0, 0, 0, 0, 30dc98) + 58 0016cf38 ber_dupbv_x (8dea98, 12f6ab0, 0, fc3ff4c8, 8000, 8de950) + 3c 0004990c ???????? (750174, 750024, 0, 0, 0, 30dc98) 00049a20 attrs_dup (750024, 3fbc50, 0, fc3ff4c8, 8000, 63) + 48 0004c7b0 entry_dup2 (3fbc6c, 3fbc44, 0, 0, 0, 30dc98) + ac 0012556c ???????? (fffffff6, fc3ffd58, 2c7208, fc3ff4c8, 8000, 63) 00125d68 ???????? (423350, fc3ffd58, 0, 0, 0, 0) 000a71c0 ???????? (8000, fc3ffd58, 9e1f38, 275fb8, 8000, a714c) 00050818 ???????? (423350, fc3ffd58, ffffffff, ffffffff, 0, 0) 00052cb8 slap_send_search_entry (0, fc3ffd58, 9e1f38, 275fb8, 3, 1f9400) + 3e0 00043c94 fe_op_search (423350, fc3ffd58, 2, 43894, 1, 0) + 400 000a7b98 overlay_op_walk (8000, fc3ffd58, 8000, 1f9b90, 8000, 200) + c8 000a7cb0 ???????? (423350, fc3ffd58, 2, fc3ffad8, 2a0bd8, 1f9c88) 00043364 do_search (423350, fc3ffd58, fee6cbc0, 1edc00, 177400, fc3ffad8) + 618 00041698 ???????? (fc3ffe08, 423350, fee6cbc0, fdcf0800, 27bb18, 0)
The second issue, which I can reproduce, is that slapd is crashing with a SIGSEGV when it encounters the following entry in a Sun Directory Server configured as a meta backend:
c=undef,dc=company
Is undef a reserved word that's causing an issue here? In earlier versions (2.4.23, at least), it seems like that entry was just discarded and not returned as a search result.
Thanks, Lincoln
On Mon, Dec 5, 2011 at 10:32 PM, Quanah Gibson-Mount quanah@zimbra.comwrote:
--On Monday, December 05, 2011 6:09 PM +0100 Lincoln Souzek < lsouzek@gmail.com> wrote:
Hello,
I've seen a couple of instances where slapd becomes unresponsive, apparently because the threads are waiting on a backend meta DB. We're running slapd 2.4.23 on Solaris 10 (update 11/06). We have 128 threads configured and when I attach with truss, I see 130 allocated, most of which look like this:
I would note there have been some re-entry fixes for back-meta since 2.4.23 was released. I would suggest you re-try with the latest OpenLDAP version as a first step.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration