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

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



Thanks for the report, it sounds like you're right.

re:2 - yes, this makes sense. The only way for an ID to appear in the 
intersection would be if there was a loop in the tree structure, which 
cannot occur here. (Loops due to aliases are handled elsewhere.) If you 
can submit the code you have, I'll take a look at integrating it. (See 
the submission guidelines at 
http://www.openldap.org/devel/contributing.html)

maxime.yve@free.fr wrote:

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


-- 
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support