[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP keeps on dying sporadically
Leander Schäfer wrote:
Ok, here is the first result running the debugging mode with gdb(1)
>> Procedure overview:
(gdb) run
(gdb) bt full
(gdb) thread apply all bt
(gdb) generate-core-file
No need for a core file if you're just running slapd inside gdb.
>> This came up:
candidates = Error accessing memory address 0x7ffffeafb6f0: Bad address.
# ================================================== #
root@FreeBSD [~]$ gdb --args /usr/local/libexec/slapd -d -1 -f
/usr/local/etc/openldap/slapd.conf -u ldap -g ldap -h
"ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldap:/// ldaps:///"
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program: /usr/local/libexec/slapd -d -1 -f
/usr/local/etc/openldap/slapd.conf -u ldap -g ldap -h
ldapi://%2fvar%2frun%2fopenldap%2fldapi/\ ldap:///\ ldaps:///
[New LWP 101138]
[New Thread 802806400 (LWP 101138/slapd)]
[...]
553e8a87 conn=1006 op=2 SRCH attr=mailAlias
553e8a87 send_ldap_result: err=0 matched="" text=""
0010: 51 bd aa 7d 3f 1c 50 fb 25 f8 59 9e 9d 9a ba 0f Q..}?.P.%.Y.....
0020: d0 07 aa 95 ac 1c e7 3e 81 f6 e6 0b 6d 09 94 9b .......>....m...
0730: 1b 51 e3 08 4b 38 ec f1 ee 8c 0f 35 cd 55 eb 80 .Q..K8.....5.U..
553e8a87 ==> limits_get: conn=1006 op=2 self="[anonymous]"
this="ou=accounts,ou=mail,dc=mydomain,dc=local"
0740: 83 e2 3b b5 13 fd 08 51 13 25 d9 7d 57 9f 6b e9 ..;....Q.%.}W.k.
[New Thread 943c11800 (LWP 100198/slapd)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 943c11800 (LWP 100198/slapd)]
mdb_search (op=0x94581c400, rs=0x7ffffebfbb60) at search.c:404
404 search.c: No such file or directory.
in search.c
Current language: auto; currently minimal
(gdb) bt full
#0 mdb_search (op=0x94581c400, rs=0x7ffffebfbb60) at search.c:404
mdb = (struct mdb_info *) 0x80290a000
id = 0
cursor = 0
nsubs = 128
ncand = 0
cscope = 0
lastid = 18446744073709551615
candidates = Error accessing memory address 0x7ffffeafb6f0: Bad
address.
(gdb) thread apply all bt
[New Thread 943c15000 (LWP 101255/slapd)]
[New Thread 943c14c00 (LWP 101213/slapd)]
[New Thread 943c14800 (LWP 101202/slapd)]
[New Thread 943c14400 (LWP 100898/slapd)]
[New Thread 943c14000 (LWP 100884/slapd)]
[New Thread 943c13c00 (LWP 100647/slapd)]
[New Thread 943c13800 (LWP 100619/slapd)]
[New Thread 943c13400 (LWP 100577/slapd)]
[New Thread 943c13000 (LWP 100531/slapd)]
[New Thread 943c12c00 (LWP 100515/slapd)]
[New Thread 943c12800 (LWP 100347/slapd)]
[New Thread 943c12400 (LWP 100311/slapd)]
[New Thread 943c12000 (LWP 100296/slapd)]
[New Thread 943c11c00 (LWP 100268/slapd)]
[New Thread 943c11400 (LWP 100165/slapd)]
[New Thread 802807800 (LWP 100103/slapd)]
Thread 19 (Thread 802807800 (LWP 100103/slapd)):
#0 0x0000000801aa78cc in __error () from /lib/libthr.so.3
#1 0x0000000801aa27f4 in pthread_mutex_destroy () from /lib/libthr.so.3
#2 0x0000000801dfc237 in flockfile () from /lib/libc.so.7
#3 0x0000000801dd7e64 in fputs () from /lib/libc.so.7
#4 0x0000000800bfd48f in lutil_debug () from
/usr/local/lib/liblber-2.4.so.2
#5 0x000000000043b96f in slapd_daemon_task (ptr=0x8028afb08) at
daemon.c:2530
#6 0x0000000801a9c4f5 in pthread_create () from /lib/libthr.so.3
Seems like something went wrong here. Am I using gdb wrong?
Looks like your liblber was installed without debug symbols. Most of
these stack traces look invalid.
Am 27.04.15 um 19:04 schrieb Michael Ströder:
Leander Schäfer wrote:
Can you please provide me a link, cause I wasn't able to find
"current RE24" on the official website nor on the FTP mirror.
Use git or this link to checkout snapshot of the RE24 branch:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/heads/OPENLDAP_REL_ENG_2_4;sf=tgz
Assuming you compiled the latest snapshot, the SEGV at
back-mdb/search.c:404 makes not much sense, it's a return statement.
Also, as back-mdb didn't exist 5 years ago, this cannot be the same
issue you've been running into all the time.
Perhaps you've hit a stack overrun. Generally slapd uses 8MB stacks on
64bit machines. It seems from your ulimit output that 8MB should be
fine, so that also seems unlikely.
What was the full LDAP search request that was running at the moment of
the crash? Mainly interested in seeing the search filter, and how
complex it was, as well as the depth of the DIT.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/