Today, one of our OpenLDAP syncrepl consumers died (again) with "ch_malloc of 0 bytes failed". Are there any known issues in 2.4.15 leading to that? It's somewhat annoying since it's the replication out mail servers are using.
The last lines before the server dies are:
Nov 2 16:38:09 kinzig slapd[17902]: conn=570825 fd=215 closed (connection lost) Nov 2 16:38:12 kinzig slapd[17902]: do_syncrep2: cookie=rid=001,csn=20091102153812.781434Z#000000#000#000000 Nov 2 16:38:12 kinzig slapd[17902]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Nov 2 16:38:12 kinzig slapd[17902]: syncrepl_entry: rid=001 be_search (0) Nov 2 16:38:12 kinzig slapd[17902]: syncrepl_entry: rid=001 cn=<CENSORED> Nov 2 16:38:12 kinzig slapd[17902]: slap_queue_csn: queing 0xa296a00 20091102153812.781434Z#000000#000#000000 Nov 2 16:38:12 kinzig slapd[17902]: slap_graduate_commit_csn: removing 0x11ac34c0 20091102153812.781434Z#000000#000#000000 Nov 2 16:38:12 kinzig slapd[17902]: syncrepl_entry: rid=001 be_modrdn (0) Nov 2 16:38:12 kinzig slapd[17902]: slap_queue_csn: queing 0xa296a00 20091102153812.781434Z#000000#000#000000 Nov 2 16:38:12 kinzig slapd[17902]: ch_malloc of 0 bytes failed
Edgar Fuß wrote:
Today, one of our OpenLDAP syncrepl consumers died (again) with "ch_malloc of 0 bytes failed". Are there any known issues in 2.4.15 leading to that?
Not sure whether that's your issue. But changes lists this:
OpenLDAP 2.4.17 Release (2009/07/13) [..] Fixed slapd global alloc handling (ITS#6054) [..]
I'd recommend to upgrade anyway.
Ciao, Michael.
Michael Ströder writes:
Edgar Fuß wrote:
Today, one of our OpenLDAP syncrepl consumers died (again) with "ch_malloc of 0 bytes failed". Are there any known issues in 2.4.15 leading to that?
(...) I'd recommend to upgrade anyway.
Indeed.
Also, you can make slapd dump core next time this happens so it's possible to get some debug info if this happens again: ulimit -c unlimited cd <directory with room for core dumps and write access for slapd user> (slapd .... -d0 &) </dev/null >/dev/null 2>&1 or use some other -d<some other value> and log to a file. The -d ensures slapd does not detach and does not do 'cd /' - which would leave the core dump in the root directory, where you likely do not want it.
Preferably use a slapd installed without stripping debugging symbols, i.e. install with ./configure make make install STRIP=""
openldap-software@openldap.org