apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: [PATCH] Re: the most common seg fault on daedalus
Date Mon, 15 Apr 2002 18:13:27 GMT
On 15 Apr 2002, Jeff Trawick wrote:

> I know; I didn't want to clutter the attempt to find the right
> solution with such details :)

Oh.  Oops.  :)

> I'm having a hard time thinking of a reasonable way to expose enough
> information so that the cleanup can be killed.  Some ugly helper
> function could be exported by APR.  Or maybe force the address of the
> cleanup function to be stored at offset 4 of the apr_mmap_t :)

I've been pondering that myself.  I can't say I'm a fan of the magic
address idea... this time.  =-]  I was wondering if we could find some
sensible addition to the semantics of apr_mmap_dup that would do the trick
for us.  Right now we have a flag that tells it whether to maintain
ownership or not.  We could have another value there that means "external
owner" or something like that.  I suppose that doesn't make any more
sense, though, than exporting a totally separate function.


None of this really gets to the bottom of the trouble.  Because in the
corefile I looked at, it wasn't just that we had already munmapped, it was
that the apr_mmap_t *itself* was not longer accessible.  I still haven't
figured out how that's possible with today's pool implementation, but
nevertheless, it happened.  Or so the corefile said.  No amount of cleanup
jiggery will fix that.  Perhaps this is indicative of something else
entirely: maybe a subrequest was run and the results of the subrequest
were not setaside into r->main's pool?  Could that explain any of this?


   Cliff Woolley
   Charlottesville, VA

View raw message