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

RE: Stack blow out



Spoke too soon. Time to wake up... Can eliminate some but not all of the extra
space needed.

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

> OK, I've figured out what I missed before. I think we can get all
> this working
> without the ridiculous stack usage. Will have something to commit
> later today.
>
>   -- 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 Kurt D. Zeilenga
> > Sent: Wednesday, January 30, 2002 11:11 AM
> > To: openldap-devel@OpenLDAP.org
> > Subject: BDB: Stack blow out
> >
> >
> > I'd really like for BDB to support every large IDLs,
> > but stack blow out is a problem even with relatively
> > small IDLs (depending on thread stack size).
> >
> > One thought I have is actually using alloca(), where
> > reliable(*), to avoid stack crashes.  alloca() actually
> > returns an error which the caller can handle.  There
> > are a couple of ways the error could be handled,
> > namely return an ALLIDS IDL or switch to malloc().
> >
> > Also, if a reliable alloca() wasn't available, the
> > code would just use malloc().
> >
> > I've also been thinking of putting in some depth
> > limits and early escape code (e.g. stop trying to
> > make very small IDLs smaller).
> >
> > Thoughts?  Comments?  Code?
> >
> > 	Kurt
> >
> >
> > * GCC builtin + a few select implementations
> >
>