Randy Kobes wrote:
For modperl_filter_new():
apr_pool_t *p; modperl_filter_t *filter; p = f->r ? f->r->pool : f->c->pool; filter = (modperl_filter_t *) apr_pcalloc(p, sizeof(modperl_filter_t));
>
before the apr_pcalloc() call, f->c->pool is defined, and p is set equal to it (f->r is null). However, sometimes what happens right after the apr_pcalloc() call is that f->r, f->c, ... of f get set to null (including f->ctx, which causes the crash in modperl_run_filter), and filter gets set to the value of p.
So it clobbers the previously allocated memory. It's possible that the pool frees that memory and f still points to the old memory and it works fine till the moment pool reallocs it for something else. But that's the whole point of pools that there is no free(), the whole pool is getting destroyed when its life is over and in the case of f->c->pool that's the life of the whole connection. Only if the connection object is destroyed the pool get destroyed as well.
Can you step into apr_pcalloc and keep an eye on the values in p and f and see what goes wrong inside of it?
Not really - only p (i.e. f->c->pool) gets passed into apr_pcalloc(). f is not visible in apr_pcalloc(), so the debugger doesn't show it. I can watch what happens to p, but I don't really know what I'm looking for and it is a rather large structure. When we return from apr_pcalloc() p itself (the pointer value) is unchanged, but f->c has gone NULL -- that's the "parent" of p (aka f->c->pool). Does p contain any pointer to f->c through which apr_pcalloc() could NULL it?
What you didn't tell me I think is whether the problem comes on the incoming or outgoing filter.
How do I tell? I have no idea what's going on here!
Another interesting temp workaround would be to cheat like so:
apr_pool_t *p = MP_FILTER_POOL(f); char *fake_data = (char*)apr_palloc(p, sizeof(ap_filter_rec_t)+ sizeof(ap_filter_rec_t)+sizeof(void)+sizeof(ap_filter_t)+ sizeof(request_rec)+sizeof(conn_rec)); modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
notice that I allocate memory for the filter and its members but don't zero them, so it won't clobber the real data. Only then I pcalloc the real memory that I'm going to use.
I tried this, and it makes no difference. Still get the same crash in the same place for the same reason.
- Steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
