apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <rbl...@gmail.com>
Subject Re: apr_pcalloc resulting in segfault
Date Thu, 31 Mar 2005 16:18:14 GMT
On Thu, 31 Mar 2005 15:37:21 +0200, Sander Striker <s.striker@striker.nl> wrote:
> Ryan Bloom wrote:

> > If the documentation says what is
> > macro, then that is almost guaranteed to be out of date at some point
> > in the future.  And, what happens when sometimes it is a function and
> > sometimes it is a macro, depending on the compiler used or what
> > #defines are set?
> It's a function when pool debugging is enabled.  Both the function and
> the macro will be present, so linking is always possible.  This was
> one of the requirements since we didn't want to inconvenience developers
> switching between debug/release builds.
> The argument that the code segfaults when apr_palloc isn't able to
> allocate any memory is moot.  Dean and others have indicated more
> than once that memory allocators usually do lazy allocation, which
> would result in segfaults in the code anyway because malloc never
> returns NULL.
> Given that, we could even opt for removing the abort callback function
> altogether.

No, we couldn't opt for removing the abort callback.  The reason that
was added, is that it isn't valid for a library to seg fault or just
abort in most situations.  The abort callback was added because HTTPd
wanted to just kill the child process ASAP.  Other applications may
want to try to print an error message in this case, so that the user
or developer can try to figure out what went wrong.

We can't gaurantee that the app will survive the call to abort, but we
need to at least attempt to give other applications the chance to
behave differently from HTTPd.


Ryan Bloom

View raw message