Re: slapd dies when given 'incorrect' requests

[David J N Begley <david@avarice.nepean.uws.edu.au>]

On Tue, 13 Apr 1999, Peter Hicks wrote:

> I've found a reproducable bug in slapd from OpenLDAP 1.2.1 - when using 
[...]
> Can anyone advise on a suitable troubleshooting route?

While we're talking about how to troubleshoot problems with slapd, I've just
run into one too (different to yours though).

Environment is OpenLDAP 1.2.1 on a Solaris 7 (SPARC) machine.  Everything had
been running smoothly, when we decided to add an extra 20,000 "dummy" user
objects for a remote authentication project we're testing.

For the first 2,000 or so objects, "ldapadd" (or Netscape's "ldapmodify",
we've been running both) kept chugging along (yes, I know it's not the most
performance-oriented way to add the objects), no problems.

Now, I've hit a problem where slapd crashes (no core, no error logged,
nothing) when adding a second entry.  Scenario runs like this:

- add a user object (ok)
- try to add a second user object (fails, Can't contact LDAP server)
- check, "slapd" not running;  restart "slapd"
- try to add second user object again (ok this time)
- try to add third user object (fails, Can't contact LDAP server)
- check, "slapd" not running;  restart "slapd"
- etc.

Using "loglevel 65535" (LOG_ANY), the syslog entries aren't really all that
helpful;  in every case, the last thing logged is:

Apr 14 01:52:12 whisky slapd[6443]: read activity on 5
Apr 14 01:52:12 whisky slapd[6443]: do_add
Apr 14 01:52:12 whisky slapd[6443]:     do_add: ndn (CN=...)

That's it.  :-(

Backend is LDBM using Berkeley DB 2.3.16.  Presumably it's falling over in the
"get the attrs" loop in "add.c" (slapd);  anything more specific I should
check before daring to place syslog function calls all over the place??


dave