max-cache-size doesn't work with 9.5.0b1

[Attila Nagy]

On 04/03/08 19:46, JINMEI Tatuya / 神明達哉 wrote:
> Hmm, this is odd in two points:
> 1. the "X" malloc option doesn't seem to work as expected.  I expected
>    a call to malloc() should trigger an assertion failure (within the
>    malloc library) at a much earlier stage.  Does it change if you try
>    the alternative debugging approach I mentioned before?  That is:
>   - create a symbolic link from "/etc/malloc.conf" to "X":
>     # ln -s X /etc/malloc.conf
>   - start named with a moderate limitation of virtual memory size, e.g.
>     # /usr/bin/limits -v 384m $path_to_named/named <command line options>
>
> 2. Whether it's related to this max-cache-size issue, the assertion
>    failure in mem.c wasn't an expected result; this is likely to be a
>    bug anyway.  If the process dumped a core, can you show the
>    stack backtrace of it?
>    (gdb) thread apply all bt full
>
>   
No effect, the process grows happily. I don't have a core dump.

> This means about 31 log messages per second.  This may not be
> extremely frequent, but if some memory is lost for every log message,
> I guess it could be a reason for the growing memory at the hight rate
> we've seen.
>
> What if you change the channel setting from:
>
>   
I've added this, so now the server doesn't log much (after start, noting):
        category default        { null; };

The memory usage still grows.

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Free Software Network (FSN.HU)                 phone: +3630 306 6758
http://www.fsn.hu/