On Wed, Mar 12, 2025 at 03:10:12PM -0400, Suresh Veliveli wrote: > Here it is.
Hi Suresh, I apologise for not really getting back to you for a while, rest assured I'm still thinking about it. However I'm still confused what might be happening and don't have much in terms of advice yet except that yes, the two (replication effectively stopping and the crash) seem to be two symptoms of the same issue. It looks like you're building OpenLDAP yourself, would you be able to apply a patch or two adding extra information to the sync logs that might help us trace this better? Are you able to compile and run OpenLDAP with -fsanitize=address in CFLAGS or an equivalent? > [root@...] # gdb ... > Reading symbols from /var/services/openldap/libexec/slapd... > BFD: warning: > /var/users/suresh.a/core.slapd.3003.bea19f5a376843abb488dce68d6e81af.5036.1741456520000000 > has a segment extending past end of file > [...] > warning: Error reading shared library list entry at 0x696e6e75723a5652 > Cannot access memory at address 0x69626f6e6e613a5e > Cannot access memory at address 0x69626f6e6e613a56 > Failed to read a valid object file image from memory. > [...] > Thread 2 (LWP 5036): > #0 0x00007f792d8868ba in ?? () > No symbol table info available. > Backtrace stopped: Cannot access memory at address 0x7ffebb22d9a0 I am a little concerned by the above warnings and the fact gdb is unable to extract any stack information at all from most threads. Doesn't seem to correspond what I'd usually see even when debugging information is missing. > Thread 1 (LWP 7650): > #0 connection_abandon (c=0x7f79158a5ba8) at connection.c:714 > o = 0x7f5fa0148170 > next = 0x7f5f90010300 In this frame, would you be able to print the following and paste/attach them here? - '*c' - '*o' - '*o->o_hdr' Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
