On Fri, 19 Sep 2003, Stas Bekman wrote: > Steve Hay wrote: > > 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.
I'll also look at this tonight ... I seem to remember that, when there's a failure, f has the same address as an f of a previously successful run-through (the failure comes at about the 3rd pass through modperl_filter_new(). > > 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. Could one also look at the value of "mode" within modperl_filter_new(), and compare to MP_INPUT_FILTER_MODE? [ ... ] > 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. I built my perl with LFS (as that's what ActiveState uses now), and built Apache out of the box. There are some warnings generally about mismatches/conversions when compiling mp2 in this regard - within modperl_filter_new(), one such warning comes from the 'apr_off_t readbytes' argument. At one point I tried putting in a typecast to appease this warning, but I was also trying other things at the time - I'll look at this more closely in isolation. -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
