RE: search_candidates on win32

["Howard Chu" <hyc@highlandsun.com>]

We need a better solution here, since an arbitrarily complex search filter
will be able to trash the server, no matter how big a stack we configure.
The current pthreads libraries put unwritable pages at the end of each stack
that is allocated, so that will prevent one thread from trashing another.
But not all threads libraries protect themselves this way, and as I recall
when you hit the unwritable page you get a SIGSEGV which kills everything
anyway, not just the offending thread.

Unfortunately it feels like we're going to have to resort to using some form
of malloc here, which is going to cost some performance in the filter
evaluation, but it seems like the only safe approach.

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

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kervin Pierre
> Sent: Sunday, March 17, 2002 11:34 PM
> To: openldap-devel
> Subject: search_candidates on win32
>
>
> Hello,
>
> I can reliably crash slapd on win32 by running a ldapsearch that is not
> scope == base. CVS-14MAR02
>
> I think the problem is in the search_candidates() function in
> servers/slapd/back-bdb/search.c ...
>
> static int search_candidates( ... )
> {
>          int rc;
>          Filter          f, scopef, rf, xf;
>          ID              tmp[BDB_IDL_UM_SIZE];
>          AttributeAssertion aa_ref;
> ...
>
> The declaration 'ID tmp[BDB_IDL_UM_SIZE];' causes a stack overflow.
>
> On my system, this evaluates to 'unsigned long tmp[131070]'.
>
> My question is, isn't that array to big?  Can someone shed some light on
> this?
>
>
> --Kervin
>
>
> --
> http://linuxquestions.org/ - Ask linux questions, give linux help.
> http://splint.org/ - Write safe C code. splint source-code analyzer.