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, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
