[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#6794) slapadd -q problems on glued databases



Full_Name: Ralf Haferkamp
Version: 2.4.23, HEAD
OS: 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (92.252.17.9)


If in a glued (hdb/bdb) setup the subordinate database has more indexes defined
than the superior database "slapadd -q" (with a LDIF that spans both databases)
will crash with a segfault, when adding the first entry to the subordinate
database.

Sample config:
------------------
[..]
database hdb
suffix "ou=people,dc=test,dc=de"
subordinate
rootdn "cn=admin,dc=test,dc=de"
directory /tmp/ldap1/
index objectclass eq
index cn eq

database hdb
suffix "dc=test,dc=de"
rootdn "cn=admin,dc=test,dc=de"
directory /tmp/ldap2/
index objectclass eq
------------------

Sample LDIF:
------------------
dn: ou=people,dc=test,dc=de
objectclass: organizationalUnit
ou: people
------------------

valgrind gives me this:
------------------
==8742== Invalid write of size 4
==8742==    at 0x4C2856C: memset (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8742==    by 0x50D396: bdb_tool_index_add (tools.c:556)
==8742==    by 0x50D8E2: hdb_tool_entry_put (tools.c:653)
==8742==    by 0x4D59DB: glue_tool_entry_put (backglue.c:1177)
==8742==    by 0x4DBF55: slapadd (slapadd.c:347)
==8742==    by 0x41CB3D: main (main.c:653)
==8742==  Address 0x77d6c00 is 0 bytes after a block of size 16 alloc'd
==8742==    at 0x4C2659D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8742==    by 0x5098C85: ber_memalloc_x (memory.c:228)
==8742==    by 0x469FE0: ch_malloc (ch_malloc.c:54)
==8742==    by 0x50C16C: hdb_tool_entry_open (tools.c:139)
==8742==    by 0x4D47E0: glue_tool_entry_open (backglue.c:758)
==8742==    by 0x4DB598: slapadd (slapadd.c:116)
==8742==    by 0x41CB3D: main (main.c:653)
==8742== 
==8742== Invalid read of size 8
==8742==    at 0x555EEE: hdb_index_recrun (index.c:457)
==8742==    by 0x50D4AF: bdb_tool_index_add (tools.c:577)
==8742==    by 0x50D8E2: hdb_tool_entry_put (tools.c:653)
==8742==    by 0x4D59DB: glue_tool_entry_put (backglue.c:1177)
==8742==    by 0x4DBF55: slapadd (slapadd.c:347)
==8742==    by 0x41CB3D: main (main.c:653)
==8742==  Address 0x77d6c00 is 0 bytes after a block of size 16 alloc'd
==8742==    at 0x4C2659D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8742==    by 0x5098C85: ber_memalloc_x (memory.c:228)
==8742==    by 0x469FE0: ch_malloc (ch_malloc.c:54)
==8742==    by 0x50C16C: hdb_tool_entry_open (tools.c:139)
==8742==    by 0x4D47E0: glue_tool_entry_open (backglue.c:758)
==8742==    by 0x4DB598: slapadd (slapadd.c:116)
==8742==    by 0x41CB3D: main (main.c:653)
==8742==
------------------

The reason for this seems to be that in a glued setup bdb_tool_entry_open()
(back-bdb/tools.c) doesn't reallocate bdb_tool_index_rec correctly when called
for the subordinate database. It is only allocated once, for the superior
database and as that one has a smaller number of indexes (bdb->bi_nattrs), it is
too small for the subordinate database.

While debugging this I also noticed that there are some more problems with
"slapadd -q" and glued bdb/hdb-databases. When the currenty entry needs to be
added to a differnent database than the previous one, slapadd will close the
current database (calling bdb_tool_entry_close()) and open the other database.
In bdb_tool_entry_close() however slapd_shutdown will be set, which will cause
the indexing tasks to immediately shutdown the next time they run. So from that
point on the indexing tasks will not run correctly anymore (even for the new
opened database).