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
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
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}
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
--On April 27, 2007 12:02:16 PM +0400 Dmitriy Kirhlarov dkirhlarov@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
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@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
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@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@sys-net.it ---------------------------------------
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
openldap-software@openldap.org
-
Dmitriy Kirhlarov -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount -
Timur Izhbulatov