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