[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
SIG 6 in openldap 2.2.x & 2.3.11
Hi,
We have an openldap server on FreeBSD. From time to it crashes with signal
6. We have started with openldap 2.2.x and now updated to 2.3.11, but the
problem is still the same.
When the signal is received Openldap has run out of memory. Normaly the
process is about 30MB and the size of the process is very stable,
regaredless what we are doing. From time to time it crashs (and I didn't had
a chance to reproduce this crash by doing anything, it just happens from
time to time...). When the crashs happens the slapd process is about 500MB.
It seems like it runs into an endless loop and in which it allocated more
and more memory.
By waiting long enough I had the chance to get a stackbacktrace from gdb
(see below). Does anybody has any idea what to do to prevent this from
happeing?
BTW. The server doesn't have to answer much ldap requests.
Gerald
slap_sl_malloc of 184 bytes failed, using ch_malloc
slap_sl_malloc of 184 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 184 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 184 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
slap_sl_malloc of 184 bytes failed, using ch_malloc
slap_sl_malloc of 192 bytes failed, using ch_malloc
ch_malloc of 192 bytes failed
assertion "0" failed: file "ch_malloc.c", line 57
Program received signal SIGABRT, Aborted.
0x283e3bac in kill () from /usr/lib/libc.so.4
(gdb) BT
#0 0x283e3bac in kill () from /usr/lib/libc.so.4
#1 0x2842513a in abort () from /usr/lib/libc.so.4
#2 0x2840114f in __assert () from /usr/lib/libc.so.4
#3 0x807ed98 in ch_malloc (size=192) at ch_malloc.c:57
#4 0x80b241c in slap_sl_malloc (size=192, ctx=0x832a680) at sl_malloc.c:266
#5 0x8155880 in ber_memalloc_x (s=184, ctx=0x832a680) at memory.c:237
#6 0x8155d8b in ber_dupbv_x (dst=0x2819fe30, src=0x9b24230, ctx=0x832a680)
at memory.c:522
#7 0x8070f90 in fe_acl_attribute (op=0x8347000, target=0x0, edn=0xbfb3dec8,
entry_at=0x82168e0, vals=0xbfb3d650, access=ACL_AUTH) at backend.c:1483
#8 0x80710cb in backend_attribute (op=0x8347000, target=0x0,
edn=0xbfb3dec8, entry_at=0x82168e0, vals=0xbfb3d650, access=ACL_AUTH) at
backend.c:1530
#9 0x8088769 in slap_acl_mask (a=0x82d1200, mask=0xbfb3e5b4, op=0x8347000,
e=0x960fc00, desc=0x8238f00, val=0x84f4128, nmatch=100, matches=0xbfb3df68,
count=11,
state=0x0) at acl.c:2107
#10 0x80855ae in access_allowed_mask (op=0x8347000, e=0x960fc00,
desc=0x8238f00, val=0x84f4128, access=ACL_SEARCH, state=0x0, maskp=0x0) at
acl.c:737
#11 0x808398a in test_ava_filter (op=0x8347000, e=0x960fc00, ava=0x84f4124,
type=163) at filterentry.c:539
#12 0x8082c1d in test_filter (op=0x8347000, e=0x960fc00, f=0x84f414c) at
filterentry.c:82
#13 0x80d49de in bdb_search (op=0x8347000, rs=0xbfbfea5c) at search.c:857
#14 0x80650db in fe_op_search (op=0x8347000, rs=0xbfbfea5c) at search.c:349
#15 0x8064ba0 in do_search (op=0x8347000, rs=0xbfbfea5c) at search.c:219
#16 0x8062531 in connection_operation (ctx=0x0, arg_v=0x8347000) at
connection.c:1061
#17 0x812d1c9 in ldap_pvt_thread_pool_submit (pool=0x81f717c,
start_routine=0x80621a8 <connection_operation>, arg=0x8347000) at
thr_stub.c:165
#18 0x8063afe in connection_op_activate (op=0x8347000) at connection.c:1678
#19 0x8063551 in connection_input (conn=0x83d9984) at connection.c:1546
#20 0x8062e9c in connection_read (s=23) at connection.c:1322
#21 0x805fc0f in slapd_daemon_task (ptr=0x0) at daemon.c:1882
#22 0x812d0cb in ldap_pvt_thread_create (thread=0xbfbff5e8, detach=0,
start_routine=0x805e364 <slapd_daemon_task>, arg=0x0) at thr_stub.c:54
#23 0x805fe5d in slapd_daemon () at daemon.c:2046
#24 0x804cb34 in main (argc=11, argv=0xbfbff6c0) at main.c:767
---------------------------------------------------------------------------
Besuchen Sie uns auf der Systems 2005 in München, Halle B2, Stand 704
---------------------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * Webapplikationen mit Apache/Perl/mod_perl/Embperl
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
---------------------------------------------------------------------------
ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
---------------------------------------------------------------------------
** Virus checked by BB-5000 Mailfilter **