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).