Bug #7295
Updated by Janos Mattyasovszky over 8 years ago
When starting slapd on a system with 1TB of RAM, it writes a coredump due a memory allocation issue.
OS: SLES11 SP3
Package: rudder-inventory-ldap-2.11.15.release-1.SLES.11
Memory: 1033740 Megabytes
<pre>
++ sed -n '/^MemTotal/s/[^0-9]//gp' /proc/meminfo
+ MEMSIZE=1058549824
+ CACHESIZE=135490000
+ sed -ie '/^[ \t]*\(cachesize\|idlcachesize\)/d' /opt/rudder/etc/openldap/slapd.conf
+ sed -ie 's/^\([ \t]*suffix[ \t]\+"cn=rudder-configuration".*\)/\1\ncachesize 135490000/' /opt/rudder/etc/openldap/slapd.conf
+ sed -ie 's/^\([ \t]*suffix[ \t]\+"cn=rudder-configuration".*\)/\1\nidlcachesize 406470000/' /opt/rudder/etc/openldap/slapd.conf
[...]
56262153 ch_calloc of 1 elems of 18446744010302859784 bytes failed
slapd: ch_malloc.c:107: ch_calloc: Assertion `0' failed.
/etc/init.d/rudder-slapd: line 359: 58757 Aborted (core dumped) $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS -d 1
</pre>
Here is the backtrace from the core:
<pre>
gdb -batch -ex bt /opt/rudder/libexec/slapd core.slapd.58757 bt
[...]
Core was generated by `/opt/rudder/libexec/slapd -h ldap://127.0.0.1:389 -n rudder-slapd -f /opt/rudde'.
Program terminated with signal 6, Aborted.
#0 0x00007fb98f48a885 in raise () from /lib64/libc.so.6
#0 0x00007fb98f48a885 in raise () from /lib64/libc.so.6
#1 0x00007fb98f48be61 in abort () from /lib64/libc.so.6
#2 0x00007fb98f483740 in __assert_fail () from /lib64/libc.so.6
#3 0x000000000044fc2c in ch_calloc ()
#4 0x000000000043dfa6 in attr_prealloc ()
#5 0x00007fb98cf551df in hdb_db_open (be=0x893400, cr=0x7ffd055011f0) at init.c:536
#6 0x0000000000443f7f in backend_startup_one ()
#7 0x000000000044428b in backend_startup ()
#8 0x000000000041a850 in main ()
</pre>
When starting the slapd with *RUDDER_CACHESIZE="noauto"* and removing the cachesize-tunings from the slapd config, then it starts.
Doing an strace on the slapd WITH memory tuning:
<pre>
21745 mmap(NULL, 35921920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f1a4673b000
21745 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f1a46733000
21745 mmap(NULL, 3145728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1a46433000
21745 mmap(NULL, 10839203840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f17c0621000
21745 mmap(NULL, 18446744010302861312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
21745 mmap(NULL, 18446744010302996480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
21745 mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f17b8621000
21745 mmap(NULL, 18446744010302861312, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
21745 --- SIGABRT (Aborted) @ 0 (0) ---
21745 +++ killed by SIGABRT (core dumped) +++
</pre>
When removing all memory tuning, it shows smaller values:
<pre>
29764 mmap(NULL, 35921920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a511a3000
29764 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a57813000
29764 mmap(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = 0x7f4a578d8000
29764 mmap(NULL, 66019328, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a4f4ef000
29764 mmap(NULL, 1073741824, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a0f4ef000
29764 mmap(NULL, 2359296, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a0f2af000
29764 mmap(NULL, 35921920, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a0d06d000
29764 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f4a0d065000
29764 mmap(NULL, 3145728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4a0cd65000
29764 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f4a0c864000
29765 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f4a0c063000
</pre>
Somehow the calculated memory size does somehow not fit for slapd on a system that big, as it tries to *allocate 18.4 exabytes* (10^10) of RAM :-D :-D :-D