On Thu, Mar 27, 2025 at 12:55:05PM +0000, Windl, Ulrich wrote:
Mar 27 12:45:32 v06 slapd[31077]: slap_sl_malloc of 93893629956635 bytes failed Mar 27 12:45:32 v06 systemd[1]: Created slice Slice /system/systemd-coredump. Mar 27 12:45:32 v06 systemd[1]: Started Process Core Dump (PID 31217/UID 0). Mar 27 12:45:32 v06 systemd-coredump[31218]: [🡕] Process 31077 (slapd) of user 76 dumped core.
Stack trace of thread 31081: #0 0x00007fa7fb8a941c __pthread_kill_implementation (libc.so.6 + 0xa941c) #1 0x00007fa7fb857842 raise (libc.so.6 + 0x57842) #2 0x00007fa7fb83f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007fa7fb83f4e7 __assert_fail_base.cold (libc.so.6 + 0x3f4e7) #4 0x00007fa7fb84fb32 __assert_fail (libc.so.6 + 0x4fb32) #5 0x0000555fefe6caca n/a (slapd + 0x9caca) #6 0x0000555fefe6d24e slap_sl_calloc (slapd + 0x9d24e) #7 0x0000555fefe296f4 build_new_dn (slapd + 0x596f4) #8 0x00007fa7fa8287c7 n/a (accesslog.so + 0x67c7) #9 0x00007fa7fa829182 n/a (accesslog.so + 0x7182) #10 0x0000555fefe23158 n/a (slapd + 0x53158) #11 0x0000555fefe2373c n/a (slapd + 0x5373c) #12 0x0000555fefe24294 slap_send_ldap_result (slapd + 0x54294) #13 0x0000555fefdfb823 n/a (slapd + 0x2b823) #14 0x0000555fefe87523 overlay_op_walk (slapd + 0xb7523) #15 0x0000555fefe876ae n/a (slapd + 0xb76ae) #16 0x0000555fefe76ffa n/a (slapd + 0xa6ffa) #17 0x0000555fefe7fd7d n/a (slapd + 0xafd7d) #18 0x0000555fefe13d30 n/a (slapd + 0x43d30) #19 0x00007fa7fbb10da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #20 0x00007fa7fb8a758c start_thread (libc.so.6 + 0xa758c) #21 0x00007fa7fb92ea28 __clone3 (libc.so.6 + 0x12ea28)
I'm not really surprised that "malloc of 93893629956635 bytes failed". The changelog before the error was:
Hard to tell, can you rebuild OpenLDAP without stripping the debug symbols out? And then open the core in gdb and issue a 'thread apply all bt full' to get a useable backtrace?
Noticing that the objectClass is auditModify, I wonder whether the recommended filter logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" is correct.
Yes, auditModify is a subclass of auditWriteObject so it matches.
The other bug I found is this: The reason for delta syncrepl not starting was my manual editing of the config.ldif used to slapadd: It seems a somehow non-matching contextCSN prevent delta syncrepl to start, or said the other way 'round: After I had deleted contextCSN from the config.ldif, the servers started to sync! However I had used slapadd option -w to load the data.
If you're modifying configuration by hand you *must* slapcat the cn=config DB, edit the LDIF and then load it back with slapadd -n0.
Since you're also replicating it, you *must* also load the hand-modified configuration with "-w". Then if you're replacing it on other servers, slapcat the resulting server configuration and load this on the other servers *without* "-w" as the replication metadata (entryCSN, contextCSN) are already populated and have to stay consistent.
I would assume the crash stems from the above not being followed but if you can still reproduce it, please file a bug with the backtrace and logs and any other information that will help us reproduce and fix the problem.
Thanks,