6:21 a.m.
Hi, list.
I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
I have reproduceble crash of slapd on this host. But I can't reproduce
it on other server (FreeBSD 6.1-STABLE Aug 2).
Database is fine (I dump and restore it), changing thread library
doesn't help too.
Some information from core:
(gdb) bt
0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2
0x2836e89a in sigaction () from /lib/libpthread.so.2
0x2836888d in pthread_kill () from /lib/libpthread.so.2
0x28368256 in raise () from /lib/libpthread.so.2
0x28442e34 in abort () from /lib/libc.so.6
0x2841f060 in __assert () from /lib/libc.so.6
0x080aad9e in entry_schema_check ()
0x286908a3 in bdb_add (op=0xcecfa0c0, rs=0xcecfa080) at add.c:63
0x080ec0b5 in overlay_init ()
0x080db272 in glue_sub_init ()
0x08080a75 in slap_req2res ()
0x080818ac in slap_send_ldap_result ()
0x08113e35 in translucent_initialize ()
0x080db309 in overlay_op_walk ()
0x080db543 in overlay_op_walk ()
0x080db650 in overlay_op_walk ()
0x0808b0c6 in fe_op_modify ()
0x0808a33e in do_modify ()
0x0806fb84 in connection_done ()
0x281b36ad in ldap_int_thread_pool_wrapper ()
from /usr/local/lib/libldap_r-2.3.so.2
0x283703a5 in pthread_create () from /lib/libpthread.so.2
0x2842e3df in _ctx_start () from /lib/libc.so.6
(gdb) info threads
6 Thread 0x818b000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
5 Thread 0x8267200 (LWP 100039) 0x2837f4f7 in pthread_testcancel () from
/lib/libpthread.so.2
4 Thread 0x8267a00 (runnable) 0x2844658b in select () from /lib/libc.so.6
3 Thread 0x8267c00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
* 2 Thread 0x8267e00 (LWP 100141) 0x2837f537 in pthread_testcancel () from
/lib/libpthread.so.2
1 Thread 0x8274000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
Can somebody help me?
WBR
Dmitriy
8:55 a.m.
May be related to ITS#4841. Perhaps the thread stack is being overrun,
you might try recompiling libldap_r with a larger thread stack size.
(LDAP_PVT_THREAD_STACK_SIZE)
Dmitriy Kirhlarov wrote:
Hi, list.
I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
I have reproduceble crash of slapd on this host. But I can't reproduce
it on other server (FreeBSD 6.1-STABLE Aug 2).
Database is fine (I dump and restore it), changing thread library
doesn't help too.
Some information from core:
(gdb) bt
0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2
0x2836e89a in sigaction () from /lib/libpthread.so.2
0x2836888d in pthread_kill () from /lib/libpthread.so.2
0x28368256 in raise () from /lib/libpthread.so.2
0x28442e34 in abort () from /lib/libc.so.6
0x2841f060 in __assert () from /lib/libc.so.6
0x080aad9e in entry_schema_check ()
0x286908a3 in bdb_add (op=0xcecfa0c0, rs=0xcecfa080) at add.c:63
0x080ec0b5 in overlay_init ()
0x080db272 in glue_sub_init ()
0x08080a75 in slap_req2res ()
0x080818ac in slap_send_ldap_result ()
0x08113e35 in translucent_initialize ()
0x080db309 in overlay_op_walk ()
0x080db543 in overlay_op_walk ()
0x080db650 in overlay_op_walk ()
0x0808b0c6 in fe_op_modify ()
0x0808a33e in do_modify ()
0x0806fb84 in connection_done ()
0x281b36ad in ldap_int_thread_pool_wrapper ()
from /usr/local/lib/libldap_r-2.3.so.2
0x283703a5 in pthread_create () from /lib/libpthread.so.2
0x2842e3df in _ctx_start () from /lib/libc.so.6
(gdb) info threads
6 Thread 0x818b000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
5 Thread 0x8267200 (LWP 100039) 0x2837f4f7 in pthread_testcancel () from
/lib/libpthread.so.2
4 Thread 0x8267a00 (runnable) 0x2844658b in select () from /lib/libc.so.6
3 Thread 0x8267c00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
* 2 Thread 0x8267e00 (LWP 100141) 0x2837f537 in pthread_testcancel () from
/lib/libpthread.so.2
1 Thread 0x8274000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
Can somebody help me?
WBR
Dmitriy
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8:38 a.m.
On Mon, Apr 23, 2007 at 08:55:30AM -0700, Howard Chu wrote:
May be related to ITS#4841. Perhaps the thread stack is being
overrun,
you might try recompiling libldap_r with a larger thread stack size.
(LDAP_PVT_THREAD_STACK_SIZE)
Dmitriy Kirhlarov wrote:
>Hi, list.
>
>I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
>I have reproduceble crash of slapd on this host. But I can't reproduce
>it on other server (FreeBSD 6.1-STABLE Aug 2).
>Database is fine (I dump and restore it), changing thread library
>doesn't help too.
Hi Howard,
Dmitriy followed your recommendations and rebuilt the openldap-server-2.3.35
port with the following variables set:
LDAP_PVT_THREAD_STACK_SIZE=268435456
WITH_DEBUG=yes
STRIP=""
He sent me more gdb output (bellow). Also, I have a test case which I use to
reproduce the crash (attached). Hope this will shed more light on the problem.
(gdb) bt
#0 0x2837f537 in pthread_testcancel () from /lib/libpthread.so.2
#1 0x2836e89a in sigaction () from /lib/libpthread.so.2
#2 0x2836888d in pthread_kill () from /lib/libpthread.so.2
#3 0x28368256 in raise () from /lib/libpthread.so.2
#4 0x28442e34 in abort () from /lib/libc.so.6
#5 0x2841f060 in __assert () from /lib/libc.so.6
#6 0x080aad9e in entry_schema_check (op=0xcecfa0c0, e=0xacbfac0, oldattrs=0x0, manage=0,
text=0xcecfa094, textbuf=0xcecf9f10 "╓'8(", textlen=256) at
schema_check.c:87
#7 0x286908a3 in bdb_add (op=0xcecfa0c0, rs=0xcecfa080) at add.c:63
#8 0x080ec0b5 in accesslog_response (op=0x8279400, rs=0xcecfad90) at accesslog.c:1175
#9 0x080db272 in over_back_response (op=0x8279400, rs=0xcecfad90) at backover.c:236
#10 0x08080a75 in send_ldap_response (op=0x8279400, rs=0xcecfad90) at result.c:303
#11 0x080818ac in slap_send_ldap_result (op=0x8279400, rs=0xcecfad90) at result.c:574
#12 0x08113e35 in unique_modify (op=0x8279400, rs=0xcecfad90) at unique.c:490
#13 0x080db309 in overlay_op_walk (op=0x8279400, rs=0xcecfad90, which=op_modify,
oi=0x8214f00, on=0x8216100) at backover.c:498
#14 0x080db543 in over_op_func (op=0x8279400, rs=0xcecfad90, which=op_modify) at
backover.c:560
#15 0x080db650 in over_op_modify (op=0x8279400, rs=0xcecfad90) at backover.c:594
#16 0x0808b0c6 in fe_op_modify (op=0x8279400, rs=0xcecfad90) at modify.c:395
#17 0x0808a33e in do_modify (op=0x8279400, rs=0xcecfad90) at modify.c:200
#18 0x0806fb84 in connection_operation (ctx=0xcecfae20, arg_v=0x8279400) at
connection.c:1133
#19 0x281b36ad in ldap_int_thread_pool_wrapper () from /usr/local/lib/libldap_r-2.3.so.2
#20 0x283703a5 in pthread_create () from /lib/libpthread.so.2
#21 0x2842e3df in _ctx_start () from /lib/libc.so.6
(gdb) info threads
7 Thread 0x818b000 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
6 Thread 0x8267400 (LWP 100039) 0x2837f4f7 in pthread_testcancel () from
/lib/libpthread.so.2
5 Thread 0x8267c00 (runnable) 0x2844658b in select () from /lib/libc.so.6
4 Thread 0x8267e00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
* 3 Thread 0x8279000 (LWP 100113) 0x2837f537 in pthread_testcancel () from
/lib/libpthread.so.2
2 Thread 0x8279200 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
1 Thread 0xacc2a00 (sleeping) 0x28377f9b in pthread_mutexattr_init () from
/lib/libpthread.so.2
(gdb) frame 6
#6 0x080aad9e in entry_schema_check (op=0xcecfa0c0, e=0xacbfac0, oldattrs=0x0, manage=0,
text=0xcecfa094, textbuf=0xcecf9f10 "╓'8(", textlen=256) at
schema_check.c:87
87 schema_check.c: No such file or directory.
in schema_check.c
(gdb) p *a
$1 = {a_desc = 0x81dad20, a_vals = 0xacb2940, a_nvals = 0xacb2940, a_next = 0xaca0840,
a_flags = 0}
(gdb) p a->a_vals[0].bv_val
$2 = 0x0
(gdb) p a->a_vals[0]
$3 = {bv_len = 0, bv_val = 0x0}
--
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:TimurIzhbulatov@oilspace.com
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com
1:02 a.m.
On Tue, Apr 24, 2007 at 07:38:56PM +0400, Timur Izhbulatov wrote:
> >I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE
(Feb 19).
> >I have reproduceble crash of slapd on this host. But I can't reproduce
> >it on other server (FreeBSD 6.1-STABLE Aug 2).
> >Database is fine (I dump and restore it), changing thread library
> >doesn't help too.
We find problem -- unique overlay.
When we remove this strings:
overlay unique
unique_base ou=users,o=oilspace
unique_attributes mail
problem is gone.
I tried add "unique_strict" but it doesn't help.
WBR.
Dmitriy
1:17 p.m.
--On April 27, 2007 12:02:16 PM +0400 Dmitriy Kirhlarov
<dkirhlarov(a)oilspace.com> wrote:
On Tue, Apr 24, 2007 at 07:38:56PM +0400, Timur Izhbulatov wrote:
> > > I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
> > > I have reproduceble crash of slapd on this host. But I can't
> > > reproduce it on other server (FreeBSD 6.1-STABLE Aug 2).
> > > Database is fine (I dump and restore it), changing thread library
> > > doesn't help too.
We find problem -- unique overlay.
When we remove this strings:
overlay unique
unique_base ou=users,o=oilspace
unique_attributes mail
problem is gone.
I tried add "unique_strict" but it doesn't help.
Did you make sure the overlay directives came at the very end of the
database configuration section? I've used unique for a long time with no
issues.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
5:27 a.m.
On Wed, May 02, 2007 at 01:17:24PM -0700, Quanah Gibson-Mount wrote:
--On April 27, 2007 12:02:16 PM +0400 Dmitriy Kirhlarov <dkirhlarov(a)oilspace.com>
wrote:
>On Tue, Apr 24, 2007 at 07:38:56PM +0400, Timur Izhbulatov wrote:
>
>>> > I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
>>> > I have reproduceble crash of slapd on this host. But I can't
>>> > reproduce it on other server (FreeBSD 6.1-STABLE Aug 2).
>>> > Database is fine (I dump and restore it), changing thread library
>>> > doesn't help too.
>
>We find problem -- unique overlay.
>
>When we remove this strings:
>
>overlay unique
>unique_base ou=users,o=oilspace
>unique_attributes mail
>
>problem is gone.
>I tried add "unique_strict" but it doesn't help.
Did you make sure the overlay directives came at the very end of the database
configuration section? I've used unique for a long time with no issues.
I'm sorry for long pause.
databases description in slapd.conf:
---------------------
# log database
database bdb
suffix "o=oilspace-log"
rootdn "cn=ldapadm,o=oilspace-log"
rootpw XXXXXXXXXXXXXXX
directory /var/db/openldap-data/oilspace-log
checkpoint 32 8
# main database
database bdb
suffix "o=oilspace"
rootdn "cn=ldapadm,o=oilspace"
rootpw XXXXXXXXXXXXXXX
directory /var/db/openldap-data/oilspace
checkpoint 32 8
overlay accesslog
logdb o=oilspace-log
logops writes
logold (objectClass=*)
logsuccess false
logpurge 182+00:00 1+00:00
overlay unique
unique_base ou=users,o=oilspace
unique_attributes mail
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
index uid,sn,cn eq
index uidNumber,gidNumber,entryUUID eq
index objectClass eq
index displayName
pres,sub,eq
index sambaSid eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
index memberUid eq
index mail eq
index uniqueMember eq
index entryCSN eq
index reqStart eq
---------------------
WBR.
Dmitriy
6:57 a.m.
I'm positive the issue is caused by the "index" directives coming
__after__ overlay instantiation, while they belong to the database
configuration. This issue has been fixed in HEAD/2.4 by partially
redesigning the way configuration is parsed, but it is not possible (I
mean: not worth the effort) to fix in 2.3, since it essentially appears
as a configuration error (configuration order matters).
p.
Dmitriy Kirhlarov wrote:
On Wed, May 02, 2007 at 01:17:24PM -0700, Quanah Gibson-Mount wrote:
>
> --On April 27, 2007 12:02:16 PM +0400 Dmitriy Kirhlarov
<dkirhlarov(a)oilspace.com>
> wrote:
>
>> On Tue, Apr 24, 2007 at 07:38:56PM +0400, Timur Izhbulatov wrote:
>>
>>>>> I'm using openldap-server-2.3.35 on FreeBSD 6.2-STABLE (Feb 19).
>>>>> I have reproduceble crash of slapd on this host. But I can't
>>>>> reproduce it on other server (FreeBSD 6.1-STABLE Aug 2).
>>>>> Database is fine (I dump and restore it), changing thread library
>>>>> doesn't help too.
>> We find problem -- unique overlay.
>>
>> When we remove this strings:
>>
>> overlay unique
>> unique_base ou=users,o=oilspace
>> unique_attributes mail
>>
>> problem is gone.
>> I tried add "unique_strict" but it doesn't help.
> Did you make sure the overlay directives came at the very end of the database
> configuration section? I've used unique for a long time with no issues.
I'm sorry for long pause.
databases description in slapd.conf:
---------------------
# log database
database bdb
suffix "o=oilspace-log"
rootdn "cn=ldapadm,o=oilspace-log"
rootpw XXXXXXXXXXXXXXX
directory /var/db/openldap-data/oilspace-log
checkpoint 32 8
# main database
database bdb
suffix "o=oilspace"
rootdn "cn=ldapadm,o=oilspace"
rootpw XXXXXXXXXXXXXXX
directory /var/db/openldap-data/oilspace
checkpoint 32 8
overlay accesslog
logdb o=oilspace-log
logops writes
logold (objectClass=*)
logsuccess false
logpurge 182+00:00 1+00:00
overlay unique
unique_base ou=users,o=oilspace
unique_attributes mail
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
index uid,sn,cn eq
index uidNumber,gidNumber,entryUUID eq
index objectClass eq
index displayName
pres,sub,eq
index sambaSid eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
index memberUid eq
index mail eq
index uniqueMember eq
index entryCSN eq
index reqStart eq
---------------------
WBR.
Dmitriy
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
7:25 a.m.
On Mon, May 14, 2007 at 03:57:11PM +0200, Pierangelo Masarati wrote:
I'm positive the issue is caused by the "index"
directives coming __after__ overlay
instantiation, while they belong to the database configuration. This issue has been
fixed in HEAD/2.4 by partially redesigning the way configuration is parsed, but it is
not possible (I mean: not worth the effort) to fix in 2.3, since it essentially
appears as a configuration error (configuration order matters).
-------
indexes
overlay accesslog
overlay unique
overlay syncprov
-------
-------
indexes
overlay accesslog
overlay syncprov
overlay unique
-------
Same effect.
WBR.
Dmitriy
6043
days inactive
6064
days old
openldap-software@openldap.org
7 comments
5 participants
participants (5)
-
Dmitriy Kirhlarov -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount -
Timur Izhbulatov