ISC решения для утечки памяти DHCPD и или обходные решения

Фон:
Я был недавно назначен ответственным за нахождение корня и/или фиксацию утечки памяти с DHCPD ISC (4.2.5-P1) установка на сервере Debian (Lenny) Unix.

Я исследовал проблему больше недели теперь и получил большую информацию о том, что система действительно протекает, но я не нашел фактический ответ относительно того, почему это или как остановить его.

Я в настоящее время имею:

• используемый valgrind в vgdb режиме, чтобы обнаружить утечки памяти и допускать контроль строки кода
• использование valgrind обнаружило 2 возможных стартовых точки для утечки
• скомпилированный источник DHCPD с CFLAGS=-DDEBUG_MEMORY_LEAKAGE_ON_EXIT (это, кажется, останавливает утечки памяти),
• выполните недавно скомпилированный двоичный файл DHCPD как dhcpd -6 -d -cf /etc/dhcpd6.conf
• взятый снимок vsz и двоичных файлов RSS в 10-минутных интервалах в течение 72 часов с помощью следующего сценария

Сценарий:

#!/bin/bash
#probably could have used watch
while [[ 0 -eq 0 ]]; do
    ps -eo vsz,rss,command | grep "dhcpd6.conf" | grep -v grep >> memory-usage.txt
    sleep 600
done

Я провел определенное исследование в области VSZ и RSS. Если размер RSS остается таким же, но увеличения размера VSZ, кажется, что существует четкая утечка памяти. Однако в моей ситуации VSZ и RSS оба увеличиваются. [Стартовый день размера 1: VZS=8560 RSS=6292 => Конечный день размера 3: VZS=67168 RSS=64860]

Я также смотрел на /proc/PID/maps видеть, мог ли я получить информацию там, но я не мог найти что-либо использования.

/proc/PID/maps информация:

08048000-081e3000 r-xp 00000000 08:05 119382     /usr/sbin/dhcpd
081e3000-081e8000 rw-p 0019b000 08:05 119382     /usr/sbin/dhcpd
081e8000-08222000 rw-p 081e8000 00:00 0
09fea000-0a11c000 rw-p 09fea000 00:00 0          [heap]
b72b7000-b72c1000 r-xp 00000000 08:01 6184       /lib/i686/cmov/libnss_files-2.7.so
b72c1000-b72c3000 rw-p 00009000 08:01 6184       /lib/i686/cmov/libnss_files-2.7.so
b72c3000-b7673000 rw-p b72c3000 00:00 0
b7673000-b77c8000 r-xp 00000000 08:01 6192       /lib/i686/cmov/libc-2.7.so
b77c8000-b77c9000 r--p 00155000 08:01 6192       /lib/i686/cmov/libc-2.7.so
b77c9000-b77cb000 rw-p 00156000 08:01 6192       /lib/i686/cmov/libc-2.7.so
b77cb000-b77ce000 rw-p b77cb000 00:00 0
b77cf000-b77d0000 rw-p b77cf000 00:00 0
b77d1000-b77d4000 rw-p b77d1000 00:00 0
b77d4000-b77d5000 r-xp b77d4000 00:00 0          [vdso]
b77d5000-b77ef000 r-xp 00000000 08:01 2022       /lib/ld-2.7.so
b77ef000-b77f1000 rw-p 0001a000 08:01 2022       /lib/ld-2.7.so
bfe0d000-bfe30000 rw-p bffdc000 00:00 0          [stack]

Вопрос (вопросы):
1. Как я должен пойти об отладке утечки памяти как это?
2. ISC говорит, что решение сбрасывает сервер время от времени и что это не ошибка. Если мой клиент не хочет сбрасывать их сервер, там какой-либо второй план? (Они хотят твердое доказательство, что они должны выполнить с решением.)
3. У кого-либо был опыт с dhcpd связанная утечка с января 2013?
4. Существует ли решение или обходное решение, доступное для этой проблемы?

Ссылка (ссылки) по теме:
1. https://kb.isc.org/article/AA-00737 (Отчет ISC)
2. https://access.redhat.com/site/solutions/402713 (Этот отчет об ошибках соответствует стартовой точке моей утечки памяти [ФУНКЦИОНАЛЬНОСТЬ OMAPI]),

Если Вам нужна дополнительная информация, которая может помочь в решении этой проблемы, я подготавливаю для обеспечения то, что я могу.

Тем временем я собираюсь видеть, могу ли я скомпилировать двоичный файл и отключить функциональность OMAPI.

DHCP 4.3.0a1 был просто выпущен, таким образом, я собираюсь видеть, изменяет ли это что-нибудь (не было никакой информации о журнале изменений об утечке ошибки, фиксируют, но не повреждает пробовать).

Спасибо за внимание.