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?
I spent another half an afternoon looking at this.
I'm trying a PROPFIND/depth: 1 for *just* DAV: getcontenttype - and I
still see steadily increasing memory use during the response with trunk
or trunk plus my patch.
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
#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
