Samisa:
> I have figured out why it did not segfault for me.
> Now when I do the fix, it segfaults. Now I do understand the real need
> for a separate global pool. I am trying to fix that next.
Sorry, Samisa, I'd missed your previous comments -- my apologies!
>> Given that, I am wondering why there is a memory growth. Could you
>> please help me understand this?
It's probably because of the way APR memory pools work. They
don't necessarily free() all the pool memory when you call
apr_pool_destroy() or apr_pool_clear(). That's left to the internal
allocator functions to decide; they may keep some of the memory
around for future use. IIRC, allocator_free() in
memory/unix/apr_pools.c is the place to look. If you want an
allocator that will free() everything immediately, you can
write such a thing and use apr_pool_create_ex(), but for use in
httpd, I think that's unwise -- just let APR do its normal memory
management for you.
>>> I hope when we do this, the memory growth would come under control.
>>> However, some effort is required to differentiate between
>>> configuration data versus per request data. (Well, the description
>>> hierarchy and some parts of the configuration hierarchy have long
>>> life. However, these may be mixed up with per request stuff.)
Yes, that's really the crux of it, I think. I figured that if
per-request and configuration data are getting mixed up, some of those
cases might be rather subtle and hard to catch. Still, I think this
would really be worth the effort, because it would simplify code
maintenance quite a bit down the road, and ensure that you don't
have to keep fighting memory leaks (or overly agressive freeing)
in one place or another.
>>> I am yet to try these suggestions. Anyway, it looks to me that we
>>> have to get rid of the macros and ops indirection altogether. And
>>> yes, it will obviously take considerable time and effort. So lets try
>>> these suggestions for 1.0 time frame.
I was trying to think of a way to retain the ops indirection and
macros, mostly just to make the task manageable, but if there are
other reasons to remove them, then I suppose that might be for the best.
But, FWIW, my original suggestion was more of a workaround solution
with the goal of trying to minimize the scope of the changes (although
it would still be a lot of effort, adding checks to all the macros).
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
|