Package: slapd
Version: 2.4.44+dfsg-5+deb9u1
Severity: normal
Dear Maintainer,
A partial replica slave crashed with
Apr 3 14:53:51 birch kernel: [1906479.552078] slapd[4515]: segfault at 4c ip
00007f71abdbfc9b sp 00007f716f184780 error 4 in
back_mdb-2.4.so.2.10.7[7f71abdb0000+39000]
Unfortunately it didn't create a core file, but I lifted the limit now.
Based on the very little data in the kernel message, it was caused by a wrong
pointer in the mdb_modify_internal() function at offset 299:
96 for ( ml = modlist; ml != NULL; ml = ml->sml_next ) {
0x000000000000fc8e <+286>: mov 0x30(%rbx),%rbx /* ml = ml->sml_next */
0x000000000000fc92 <+290>: test %rbx,%rbx /* exit if NULL */
0x000000000000fc95 <+293>: je 0x10410 <mdb_modify_internal+2208>
97 int match;
98 mod = &ml->sml_mod; /* mod = ml */
99 switch( mod->sm_op ) {
0x000000000000fc9b <+299>: movzwl 0x1c(%rbx),%eax /* read mod->sm_op */
0x000000000000fc9f <+303>: test %ax,%ax /* test for LDAP_MOD_ADD */
0x000000000000fca2 <+306>: jne 0xfc88 <mdb_modify_internal+280>
As far as I understand it, ml (in %rbx) must have been 0x30=0x4c-0x1c
there, which is an invalid value. By coincidence, the offset of
sml_next is also 0x30 in the structure pointed to by ml, because the
size of struct Modification (ml->sml_mod) is 0x30 bytes. I can't see
how these quantities could enter %rbx, though, just noting it.
Does this ring any bells? This crash does not happen frequently, so I
decided to report this little info now, but I'll add more as I got any.
--
Thanks,
Feri.
