https://bugs.openldap.org/show_bug.cgi?id=9254
--- Comment #4 from Claudio c.dosio@gmail.com ---
There are three issues in my opinion:
- Shouldn't slapadd make some checks on data type values and eventually
either give an error or change an exceeding value to the minimum/maximum value of the range?
slapadd generally does very few validity checks. It is intended to be used on >LDIFs that are known to be valid, i.e. for loading the output of slapcat.
This is correct if the dump were valid, in this particular case the dump contained an invalid data which then made instable slapd. Would it be possibile, maybe activating it by a flag, to add validity checks while importing? It could save from headaches further down the road. It took me quite a bit of time to pinpoint the problem to that value being out of bound
- Shouldn't slapd manage the exceeding value instead of freezing (in a way
coherent to point 1)?
Indeed, slapd shouldn't freeze. You should provide a gdb stack trace of the >running threads when this situation occurs.
I will try to give a gdb stack as soon as I can manage to replicate the problem on another PC (the one I fixed it on is being used).
- Shouldn't slapcat be forced to skip over the problem of an out of range
value at least if run with the "-c" flag?
slapcat does no validity checks; it assumes the contents of the DB it is >reading are valid. In most cases the -c flag is meaningless for slapcat.
In my particular case slapcat would stop at 32768 bytes and I have so send it a SIGKILL to close it. Probably the value is so much out of range that it gives problems also in reading it from the underneath DB. I left it for several minutes before killing the process.
What I will try to understand with my collegues is how that out of bound value has been accepted in the first place, or how it was forced.