Stas Bekman wrote:
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.
Yes, but you can get the address contained in f before you dive into apr_pcalloc.
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?
Not specifically about f->c, but internally it knows all the allocations. That's why I mentioned that everything else fails we need to move on to enabling debug support in the pools.
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!
just disable one in the test and see whether it's the incoming or outgoing on that fails.
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.
OK, so it probably somewhere else.
One other explanation could be type sizes mismatch between perl and apr, but I don't see anything like this happening in here. Though this is something that needs to be checked. Usually this happens if apache and perl are not both build with large_files or w/o. e.g. we have this problem in apr/perlio's seek function. I was passing the value to seek to and the function would convert it to zero. later with help of Nick S.I. from p5p I have learned that the problem was in the type mismatch, perl was passing 64 bit int and apr was accepting 32 bit int, and voila some kind of truncation/alignment was happening.
In any case can you check whether you have both perl and apache built with largefiles or both without? Just check whether you have MP_LARGE_FILES_CONFLICT defined in src/modules/perl/mod_perl.h
Index: src/modules/perl/mod_perl.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.60
diff -u -r1.60 mod_perl.h
--- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
+++ src/modules/perl/mod_perl.h 19 Sep 2003 09:11:47 -0000
@@ -43,6 +43,10 @@
#define MP_LARGE_FILES_CONFLICT \
!(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)+#ifdef MP_LARGE_FILES_CONFLICT +#error "Large files conflict!" +#endif + #ifdef MP_USE_GTOP #include "modperl_gtop.h" #endif
if it fails to compile you have this conflict.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
