[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SIG 6 in openldap 2.2.x & 2.3.11
I didn't analyze the backtrace deep enough, but I note that it refers to
fairly new and 2.3 specific code, so it's quite strange you were gtting
the same issue with 2.2. Looks like some circular condition in ACL
evaluation. I suggest you file an ITS providing the backtrace and your
ACLs (sanitized as little as possible compatibly with your confidentiality
needs).
p.
> 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 **
>
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497