[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd hanging - meta backend - Solaris 10

To: Quanah Gibson-Mount <quanah@zimbra.com>
Subject: Re: slapd hanging - meta backend - Solaris 10
From: Lincoln Souzek <lsouzek@gmail.com>
Date: Mon, 12 Dec 2011 11:15:48 +0100
Cc: openldap-technical@openldap.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bPKbqWrOcg9VoTIGg8CDqVbaaPa7J3d8dnFMjNEcGtA=; b=EWvgR2/ggg5gmJuegfTnrAk6rnU5ztwHwvemx0X7nZ6n9SwJoDejfk7MlLi4Mywg+N sm1/yAhQD7cZT0MZ1+JrymYvtXH/vyOFTEbKrsH/cZu5mQdAeaBpRaDdfQPWKskWVZrI TbgusDth+EN15UAw2LAqpiHIXIZnBeaAn8deA=
In-reply-to: <40A2F8DD6C60A3B977D0E378@192.168.1.23>
References: <CA+x7ExAphuu9OeHU1FUM2ajj9LwTWySRt4ie7kFv+AtiNHwjSA@mail.gmail.com> <40A2F8DD6C60A3B977D0E378@192.168.1.23>

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.com> wrote:

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

References:
- slapd hanging - meta backend - Solaris 10
  - From: Lincoln Souzek <lsouzek@gmail.com>

Prev by Date: I have no name!
Next by Date: SSL/TLS testing
Index(es):
- Chronological
- Thread