On 06/24/2019 07:04 PM, Joe Orton wrote:
> On Fri, Feb 08, 2019 at 08:07:57AM +0100, Ruediger Pluem wrote:
>> On 11/13/2018 10:26 AM, Joe Orton wrote:
>>> On Mon, Nov 12, 2018 at 08:26:48AM +0100, Ruediger Pluem wrote:
>>>> The discussion died a little bit, because of the other issue (frequent
>>>> writeev calls). I know that the liveprops issue is not fixed yet, but
>>>> I guess it makes sense if you commit the patch you posted here
>>>> already.
>>>
>>> Sorry, I was looking at this again and the repro case I thought worked
>>> was still showing leaks, so I got stuck. Will come back to it hopefully
>>> later this week.
>>>
>>
>> Going through the STATUS of 2.4.x I got aware that this died a little bit
>> again.
>> Any new ideas in the meantime?
>
>
> If I break in sbrk the memory allocation which triggers a heap expansion
> is within some r->pool for the subrequest, so I suppose the bug is
> around subreq handling somehow, but it's far from obvious.
>
> #0 0x00007f8111b60130 in sbrk () from /lib64/libc.so.6
> #1 0x00007f8111af54cd in __default_morecore () from /lib64/libc.so.6
> #2 0x00007f8111af18a3 in sysmalloc () from /lib64/libc.so.6
> #3 0x00007f8111af2a3f in _int_malloc () from /lib64/libc.so.6
> #4 0x00007f8111af3b8f in malloc () from /lib64/libc.so.6
> #5 0x00007f8111c7cd34 in allocator_alloc (in_size=8152, allocator=0xfd69f0)
> at memory/unix/apr_pools.c:411
> #6 apr_pool_create_ex (newpool=newpool@entry=0x7ffe8dc303f8,
> parent=0x16fe6b8, abort_fn=0x440d90 <abort_on_oom>,
> abort_fn@entry=0x0, allocator=0xfd69f0, allocator@entry=0x0) at
> memory/unix/apr_pools.c:1079
> #7 0x0000000000461a4a in ap_location_walk (r=r@entry=0x16fe730) at
> request.c:1487
> #8 0x0000000000462164 in ap_process_request_internal (r=0x16fe730) at
> request.c:238
> #9 0x0000000000462cc8 in ap_sub_req_method_uri (method=method@entry=0x47a6a0
> "GET",
> new_uri=0x16fc6a8 "/modules/dav/file.b626.txt", r=0x100afb0,
> next_filter=next_filter@entry=0x0) at request.c:2346
> #10 0x0000000000462d03 in ap_sub_req_lookup_uri (new_uri=<optimized out>,
> r=<optimized out>,
> next_filter=next_filter@entry=0x0) at request.c:2359
> #11 0x00007f8110ce6448 in dav_do_prop_subreq (propdb=0x100cfc0) at props.c:331
What if you go here and do a
dump_all_pools propdb->p
and do it again when you hit the next sbrk and the next one and so on?
Something suspicious?
> #12 0x00007f8110ce665d in dav_insert_coreprop (propdb=propdb@entry=0x100cfc0,
> propid=<optimized out>,
> name=0x1014e18 "getcontenttype", what=what@entry=DAV_PROP_INSERT_VALUE,
> phdr=phdr@entry=0x7ffe8dc30550,
> inserted=inserted@entry=0x7ffe8dc30548) at props.c:390
> #13 0x00007f8110ce73b5 in dav_insert_liveprop (what=DAV_PROP_INSERT_VALUE,
> elem=0x1014da8, elem=0x1014da8,
> inserted=0x7ffe8dc30548, phdr=0x7ffe8dc30550, propdb=0x100cfc0) at
> props.c:457
> #14 dav_get_props (propdb=0x100cfc0, doc=<optimized out>) at props.c:871
> #15 0x00007f8110cdf7c9 in dav_propfind_walker (wres=0x7ffe8dc307b8,
> calltype=<optimized out>) at mod_dav.c:2055
> #16 0x00007f8110be4885 in dav_fs_walker (fsctx=fsctx@entry=0x7ffe8dc307b0,
> depth=depth@entry=1) at repos.c:1600
> #17 0x00007f8110be4df9 in dav_fs_internal_walk (params=0x7ffe8dc30a50,
> depth=1, is_move=0, root_dst=0x0,
> response=0x7ffe8dc30a48) at repos.c:1844
> #18 0x00007f8110ce083b in dav_method_propfind (r=r@entry=0x100afb0) at
> mod_dav.c:2192
> #19 0x00007f8110ce37f8 in dav_handler (r=0x100afb0) at mod_dav.c:4814
>
>
Regards
Rüdiger
