reproducible memory leak when xcache.size is set too small to process a request

[cloph]

A Virtualbox image to reproduce the memory leak is available here:
 http://buildbot-linux-1.documentfoundation.org/VMs/ (downloadsize around 380MB, extracted size ~1.1GB)

When xcache.size is set too a value too small to process a request, memory usage grows limitless, the bigger the difference between assigned and needed memory, the faster the memory usage grows.

Setup to reproduce:

* Apache with mod_fcgid, only one child process (to ensure all requests go to the same worker for ease of seeing the effect), and the default of 500 requests per process
* I use silverstripe as php-application to accelerate
* ab -n 499  http://localhost/ with xcache of 16M (i.e. large enough): no problem, everything is fine
* set xcache.size to value < 7M (that's approx. what is needed to process the homepage request in the blank setup), for example 4M
* restart apache or request the homepage once more to spawn a new worker that makes use of the changed setting
* ab -n 499  http://localhost/ once again, this time memory grows and grows until OOM-killer intervenes,

and it is not a couple of bytes with each request, it easily is more than one MB with each request.

[moo]

access denied. pls fix the file permission on xcache-memleak.ova

[cloph]

uups, sorry, permissions fixed.

[moo]

it's not us keyboard and i don't have root access, any tips?

[moo]

never mind, i have workaround it

[cloph]

Sorry for not explaining it - ubuntu doesn't have a dedicated root user, everything is done using sudo (just do sudo bash to get a shell with root-permissions if you like), and I prefer to ssh into the VM (so the internal keyboard layout doesn't matter). To change the layout temporarily: "loadkeys us" (as it's a german layout type "loadkezs us" - z and y are switched), to configure permanently use sudo dpkg-reconfigure console-data

[moo]

sure, sudo -s, dpkg-reconfigure console-setup

fixed in [705] for trunk, in [708] in 1.3