mhardin@symas.com wrote:
This clearly explains the assertion pcache is reporting. Well-intended behavior or not, there is a problem here because pcache takes down the server whenever it encounters attribute values of this form.
No longer :)
Given Kurt's later comments about the provenance and ancestry of this "standard", it seems to me the right thing for back-meta (and back- ldap, for that matter) to do might be to just make the attribute completely disappear. Appropriate messages output in debug mode or at a particular log level might announce the fact that the attribute is being disappeared. The pcache overlay, for its part, instead of asserting, might instead log a warning and refuse to cache the object.
Sound reasonable?
See latest commit. If this fixes your problem, a message like
conn=X op=Y meta_send_entry("cn=smtg"): slap_bv2undef_ad("member;range=Z-W"): ...
Maybe you're not seeing it because slapd dies before logging? I could recreate the issue by entering slapd with gdb, let it get the attribute name, modify it by putting a "=" in between, and letting things go through. What happened is that slapd does not recognizes the attribute and continues the cycle. The subsequent attribute is not recognized as well because it is actually the first value! This should now be handled correctly.
Please test.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------