Re: (ITS#3609) ch_malloc of 8388608 bytes failed

[hyc@symas.com]

You can get the BerkeleyDB patch here
http://www.openldap.org/devel/cvsweb.cgi/build/BerkeleyDB42.patch

You will also need a patch in back-bdb/cache.c, get the diff from 1.92 
to 1.94 of that file.

But for the moment I wouldn't bother with either of those patches as 
they have no bearing on the amount of memory being used.

By the way, try "info threads" in gdb as well, that would give us a 
better idea of what other threads are active.
Also, how much memory total is on the system? What does "top" show for 
memory usage? It seems to me that there is no software issue here, 
you're just trying to run in an environment with inadequate resources.

Bob Smith wrote:

> I switched to db-4.2.52.NC and applied the four patches they list on 
> their site,
> patch.4.2.52.1 through 4.  You mentioned another patch from the 
> OpenLDAP site
> which I have not been able to find -- I would appreciate a pointer.
>
> With the above four patches, I configured, compiled, and installed 
> another
> instance of slapd, but had no joy.  However, this time it failed on an 
> allocation of 1MB:
>
> ber_get_next
> >>> dnNormalize: <cn=sudleyplace,ou=Groups,dc=Qualitas,dc=com>
> => ldap_bv2dn(cn=sudleyplace,ou=Groups,dc=Qualitas,dc=com,0)
> ber_get_next: tag 0x30 len 6 contents:
> ldap_err2string
> ber_get_next
> do_abandon
> <= ldap_bv2dn(cn=sudleyplace,ou=Groups,dc=Qualitas,dc=com)=0 Success
> ber_scanf fmt (i) ber:
> ber_get_next: tag 0x30 len 147 contents:
> => ldap_dn2bv(272)
> connection_input: conn=0 deferring operation: too many executing
> ldap_err2string
> <= ldap_dn2bv(cn=sudleyplace,ou=groups,dc=qualitas,dc=com)=0 Success
> <<< dnNormalize: <cn=sudleyplace,ou=groups,dc=qualitas,dc=com>
> bdb_search: 22 does not match filter
> do_abandon: op=3 found
> ch_malloc of 1048576 bytes failed
> assertion "0" failed: file "ch_malloc.c", line 62
>
> As before, I have uploaded a copy of the output from
>
> thread apply all bt full
>
> to my website at http://www.sudleyplace.com/backtrace.html
>
> Also, this LDAP server is not publicly known, so no one else is using 
> it as yet, so there is no other activity, although other servers on 
> the same site are very much in use.  Another other ideas?
>
> On 3/30/2005 8:01 PM, Bob Smith wrote:
>
>> Thanks for your comments.  The threads setting is at 4.
>>
>> I guess I'll stick with bdb, but switch to 4.2.52 (with patches).
>>
>> On 3/30/2005 5:53 PM, Howard Chu wrote:
>>
>>> I do not recommend reducing the size of the searchstack. Instead, 
>>> decrease the maximum number of threads from the default of 16 to 
>>> something much lower. The fact that your backtrace only shows one 
>>> thread running is probably just an artifact of the debugging 
>>> environment not being able to get full status information after a 
>>> fatal exception. This frequently happens if the gdb binary was 
>>> compiled against a different version of libc headers than you're 
>>> currently running under. At any rate, the lack of information about 
>>> other threads is not a reliable indicator of the program's actual 
>>> thread state.
>>>
>>> The back-ldbm backend has lower memory requirements but is not 
>>> recommended for any deployments because it has locking and stability 
>>> issues.
>>>
>>> bsmith@sudleyplace.com wrote:
>>>
>>>> No sooner had I configured <slapd.conf> as described below and then 
>>>> tested it exactly as before, did it crash again.  This time I ran
>>>>
>>>> thread apply all bt full
>>>>
>>>> but apparently there was only one thread running.  As before, I put 
>>>> all this onto my web site at
>>>>
>>>> http://www.sudleyplace.com/backtrace.html
>>>>
>>>> Any suggestions you can make as to different values for these 
>>>> parameters or other parameters, please let me know.  Also, I'd be 
>>>> willing to try a less memory-hungry backend if you think that'll help.
>>>
>


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support