Greg Ames wrote:
Jeff Trawick wrote:problem not seen in 2.0.43, but seen in HEADI think the 22 is EINVAL inside the include filter from the attempt to
read a bogus mmap bucket.
My recent changes to core_output_filter can drive cleanups sooner than they were before. I suspect that has something to do with the bogus mmap bucket.
Recreated but not fully understood.I'll see if I can recreate this.
mmap_bucket_setaside creates a dup of the mmap bucket in my new deferred write pool. forking/execing the script adds a FLUSH bucket somewhere behind the mmap bucket. This causes a socket write and then my new code clears the pool, driving mmap_bucket_cleanup, which zeros out the pointer to the apr_mmap_t.
Later this zeroed out pointer causes mmap_bucket_read to return APR_EINVAL. That seems to imply that mod_include is getting a pointer to the dup'ed + cleaned up mmap bucket somehow, which I don't understand. Any words of wisdom from mod_include and/or bucket experts would be appreciated.
In the mean time, I'm thinking of hacking core_output_filter to wait to clear the deferred write pool until it sees an EOS, or just restoring it to the 2.0.43 level until we can figure out why this scenario doesn't work properly.
Greg
