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. BUT........................ 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 -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
