[Mono-list] Mono runtime Garbage Collection behaviour

[Paolo Molaro]

On 01/28/05 Hinne Hettema (DSL AK) wrote:
> export GC_FIND_LEAK=1
> 
> The latter flag lets the garbage collector work as a memory leak
> detector.

GC_FIND_LEAK only makes sense when libgc is used as a malloc replacement.
It's normal that you get the leak messages with mono, because we
won't free explicitly the memory: it will be collected.
We'll likely disable that feature in the internal build, so users
don't get confused.

> The background to this problem is that we are deploying a large website
> on mono for a customer, and have the server 'freeze' about 1-2 times a
> day. At the freeze points mono takes up between 15-55% of memory on the
> web server, typically consumes around 3% of CPU, and the website becomes
> responsive again if the mono processes are restarted.

Any chance you can use gdb and get a stack trace of all the running threads?
Get the pid of the mono process and then use:
	gdb /path/to/mono pid
and at the gdb prompt issue:
	t a a bt
and mail us the output.

You may also want to try mono 1.1.3 or the soon to be released 1.1.4.

> 1. Is the above behaviour for mono with this test case normal or
> expected? Is this test case supposed to work on mono without the 'Leaked
> composite object..' bits?

It's normal, see above, that feature is only relevant for using libgc
as a malloc replacement.

> 3. Are there known instances where other unix processes (such as log
> rotation, backups, rsynchs) interfere with mono processes?

There should be no such interference.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better