(ITS#3647) Segmentation fault search sublevel back-hdb

[maxime.yve@free.fr]

Full_Name: Maax
Version: 2.2.24 & 2.2.17
OS: linux / debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.67.120.34)


Hi!

1 - Segmentation Fault Problem

backend is hdb. (We tested it and reproduced it on 2.2.24 and 2.2.17, We didn't
test it on other version.)

We work on a node (not the root node) where there is more than 300.000
sub-entries  with 17.000 direct children.

When we do a search sub-level ( doesn't matter the filter ), slapd crash with
segmentation fault.

So I added trace and it seems that the problem appears in the bdb_idl_union
function.
This function is called in hdb_dn2idl_internal (line 1054).

bdb_idl_union( cx->ids, cx->tmp );

cx->tmp is declare as ID tmp[BDB_IDL_DB_SIZE] on dn2id_cookie

and in bdb_idl_union the limit is define with BDB_IDL_UM_SIZE.

I replace BDB_IDL_DB_SIZE by BDB_IDL_UM_SIZE on the dn2id_cookie struct
declaration, and it seems to fix the problem.

Could you tell me if I'm wrong ?

2 - Performance Problem.

A search (with indexed filter attributes) on this node took 40s on hdb against >
0.5s on bdb.

With help of trace, we saw that the most of the time is spent on bdb_idl_union.
(idlcachesize is set to 80.000)

My hypothese is that the intersection between cx->ids and cx->tmp are always
empty when we descend the tree recursively? I don't known if it's really right,

but I replace the bdb_idl_union by a bdb_idl_append function which just append
cx->tmp to cx->ids. I sorted cx->ids afterward.

The obtained performance (with our data) is near bdb performance, on our data we
obtain the same search result for some test case.

But i'm afraid of the regresion risk. Could you tell me if my hypothese is good
?

Maxime