Re: slapcat segfaults in certain backglue setups (ITS#2924)

[rhafer@suse.de]

On Fri, Jan 16, 2004 at 10:07:56AM -0800, Howard Chu wrote:
> 
> > -----Original Message-----
> > From: owner-openldap-bugs@OpenLDAP.org
> > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of rhafer@suse.de
> 
> > Full_Name: Ralf Haferkamp
> > Version: 2.1.25, 2.2.4
> > OS: SUSE Linux
> > URL: ftp://ftp.openldap.org/incoming/
> > Submission from: (NULL) (212.95.106.42)
> >
> >
> > When I use an back-ldap database as a subordinate of some
> > bdb- of ldbm-
> > Database. slapcat will segfault after the contents of the
> > bdb/ldbm Database have
> > been dumped.
> > I was not able to produce a reasonable backtrace yet, but it
> > seems to crash in
> > backglue.c inside the glue_tool_entry_first function when
> > trying to call
> > be_entry_open
> > for back-ldap (which does for good reasons not provide the function).
> 
> Thanks, this is now fixed in HEAD. Please test.
The fix didn't completely work. I just checked an additional small fix into
HEAD which checks for the availability of glueBack->be_entry_close before
calling it. Now it works for me.
 
> > Wouldn't it be good to completely ignore the subordinate
> > stuff when operating with the slaptools?
> 
> You always have the option to do this, if you e.g. use slapcat -n to cat a
> specific backend, the subordinate stuff is ignored.
Hmm, this doesn't seem to work correctly then. I used the following setup
for my test:

database        bdb
subordinate
directory       /var/lib/ldap2
lastmod         on
mode            0600
suffix          "ou=people,dc=suse,dc=de"
rootdn          xxxxxx
rootpw          xxxxxx

database        bdb
directory       /var/lib/ldap
lastmod         on
mode            0600
suffix          "dc=suse,dc=de"
rootdn          xxxxxx
rootpw          xxxxxx

calling slapcat -n 1 correctly dumps only the first database 
("ou=people,dc=suse,dc=de") but if I call slapcat -n 2 both databases are
dumped.

> However, it's still
> desirable to have the subordinate functionality when you're doing a bulk
> load; it saves you from having to split your input LDIF into multiple files.
Yes, you are right.

-- 
Ralf