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

[bsmith@sudleyplace.com]

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.

-- 
_______________________________________________________________
Bob Smith - bsmith@sudleyplace.com - http://www.sudleyplace.com
a.k.a.      bsmith@qualitas.com    - http://www.qualitas.com