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

Задний план:
Недавно мне поручили найти корень и / или исправить утечку памяти с помощью установки ISC DHCPD (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 / информация о картах:

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 FUNCTIONALITY])

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

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

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

Спасибо за ваше время.