Re: Slapd Crashes on Asertion Failed

[Pierangelo Masarati <masarati@aero.polimi.it>]

> > well, the fix is very easy: bail out everytime garbage comes in;
> > however, I think it's better to stop the garbage at the door rather
> > than when it's already in.  I couldn't reproduce the problem with any
> > of the tools/library calls, so the problem should be with YOUR client.
> > You were expected to provide a complete dump of the BER code that
> > caused the crash, I suppose.  That would really help.
> 
> I was using Perl's Net::LDAP, so I doubt the problem was there.  Now the
> same problem is with PHP, so again, I'm doubtful.
> 
> I talked to Kurt about this, and I've already sent him dumps, and I believe
> we got down to a BER dump eventually (what is "BER" anyway?).  He said the
> assert() is there to prevent flaws in openldap's logic, so there's obviously
> something wrong somewhere...

The BER dump means a dump of what (BER encoded) is sent over the wire.
BER is Basic Encoding Rules, the format in which information is exchanged
by LDAP (and other protocols, I suppose).  You should sniff what the
client is sending to the server when it crashes (or add some extra
debug code that dumps ALL the stuff that's coming in in hex).

The point, I guess, is that a "modify" with NULL values is in fact 
a "delete".  If you try to ldapmodify an entry with

dn: <some dn>
changetype: modify
replace: <some attr>
-

with the ldapmodify tool that comes with OpenLDAP, everything works fine,
i.e. the attr is deleted, and if it does not exist, it is not created.
If you can point out the differences between this message an the one that
originates from PERL or PHP, we can try to find where the decoding
part of slapd leaks or misinterprets the message (assuming the problem
is there).

Pierangelo.