AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -----Ursprüngliche Nachricht-----
> Von: Joe Orton <jor...@redhat.com>
> Gesendet: Dienstag, 25. Juni 2019 13:59
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Tue, Jun 25, 2019 at 09:06:42AM +0000, Plüm, Rüdiger, Vodafone Group
> wrote:
> > > On Tue, Jun 25, 2019 at 08:49:08AM +0100, Joe Orton wrote:
> > > > Unless I am missing something the apr_dir_open/apr_dir_read API
> design
> > > > is always going to have memory use proportional to directory size
> > > > because apr_dir_read() duplicates the filename into the
> directory's
> > > > pool.  We need an apr_dir_pread() or whatever which takes a pool
> > > > argument. :(
> > >
> > > OK, yes, this plus an iterpool in dav_fs_walker() fixes it.
> >
> > Only the iterpool in dav_fs_walker or plus the changes in APR
> (apr_dir_pread)?
> 
> Yes, both - PoC attached but I'm not at all confident this is safe, esp
> in the recursion case.
> 
> The test I was running before was only a "core" liveprop provided by
> mod_dav itself, so I also tested the deadprops case and that still seems
> to leak.  sbrk() to increase the heap is getting triggered by
> apr_sdbm_open() every time I saw it, but apr_dbm_open() is being pass
> the scratchpool so I think it's not the cause.

I would agree, but can you please provide the stacktrace up to sbrk?
That would ease it for me to dive in :-).

> 
> Running "dump_all_pools propdb->p" at this point gives me:
> 
>    Pool 'transaction' [0x24e1d88]: 7264/8192 free (1 blocks) allocator:
> 0x24d2b90 free blocks in allocator: 0 kiB
>      Pool 'master_conn' [0x2504e28]: 1224/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>        Pool 'deferred_pool' [0x263ef18]: 8032/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>          Pool 'request' [0x2506e38]: 13672/1646592 free (201 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>            Pool 'mod_dav_fs-walker' [0x2524648]: 8016/8192 free (1
> blocks) allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>            Pool 'mod_dav-scratch' [0x2508e48]: 7224/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>            Pool 'mod_lua-vm' [0x250ce68]: 6360/16384 free (2 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
> 
> [trimmed some whitespace only]
> 
> I think this is implicating misuse of r->pool, that's grown rather
> large?
> 

I would think so as well.

Regards

Rüdiger