Re: Replication bug with modrdn changetype (ITS#1562)

[masarati@aero.polimi.it]

enigma@apu.edu wrote:
> 
> On Tue, 29 Jan 2002, Pierangelo Masarati wrote:
> 
> Yes.  I can search with either the OLD or the NEW and it yeilds the same
> entry.  The dn for that entry is reported as being the OLD dn.  It's really
> bizzare!  It only happens with the replicated server, not the master.

Not that bizarre, because the dn you see in the entry is part of the
entry 
data, which, due to a problem, can be different to the one that's
indexed
(of course it is a bug!)

But the point is: the bug may have occurred earlier, and the failure of 
the modrdn could be the result of mangled indices.  A backtrace will 
definitely help.

> 
> > > The master LDAP server does not crash.  It is not in an inconsistent
> > > state.  Only the slave ldap server.
> >
> > A backtrace of the slave, to determine why it crashed, would help.
> > Is the problem repeatable (same/analogous entry, same/analogous
> > change resulting in the same disaster)?
> 
> How do I perform a backtrace?  Is it possible to get the backtrace after
> the server has crashed?  There doesn't seem to be a core dump.
> 
> The problem is repeatable.  Issuing a modrdn request, whether or not I
> specify a newsuperior, will always cause the replicated server to crash in
> an unstable state.
> 

well, as the problem is so repeatable you can launch the slave slapd 
under a debugger (use the compiled version, the installed one gets 
stripped off the debugging symbols):

[slave]$ gdb PATH_TO/slapd
> r -f PATH_TO/slapd.conf -h 'ldap://' -d 0
<...>
> (SIGSEGV or so)

When the process crashes, issue a "bt" command:

> bt

a full log (e.g. slapd -d -1), limited to the last modrdn part (roughly 
from the last occurrence of "do_modrdn" to the end) can be of help.


> More Hardware/Software Issues:
> * Intel PII, SMP with 2 processors
> * RedHat 7.1
> * OpenLDAP 2.0.21 (built from source)
> * db3-3.1.17-7 (from stock RedHat 7.1 RPM)
> 
> ./configure             \
>   --enable-syslog       \
>   --with-cyrus-sasl     \
>   --with-readline       \
>   --with-threads        \
>   --with-tls            \
>   --enable-cleartext    \
>   --enable-crypt        \
>   --enable-spasswd      \
>   --enable-wrappers     \
>   --enable-slurpd

I don't see any critical configuration twirk.  Of course, I know there
were thread issues with glibc released under RH7.1, and you should check 
how db3 was compiled (what threads and thread configuration it used).

You may try a rpm --rebuild db3*.src.rpm (or something like that) 

Pierangelo.

-- 
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 |
mailto:pierangelo.masarati@polimi.it
via La Masa 34, 20156 Milano, Italy   |
http://www.aero.polimi.it/~masarati