Bug 19572 - Утечка памяти в обёртке к getaddrinfo
Summary: Утечка памяти в обёртке к getaddrinfo
Status: CLOSED WORKSFORME
Alias: None
Product: Sisyphus
Classification: Development
Component: krb5 (show other bugs)
Version: unstable
Hardware: all Linux
: P3 major
Assignee: Sergey Bolshakov
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-10 18:05 MSD by Evgeny Sinelnikov
Modified: 2018-12-05 15:23 MSK (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evgeny Sinelnikov 2009-04-10 18:05:49 MSD
В функции-обёртке krb5int_getaddrinfo() обнаружена утечка памяти. Проблемы такого рода периодически проявляются в рассылках MIT Kerberos...

Текущая проблема не единственна, к тому же потенциально известна разработчикам- они и так знают, что там всё криво... у них так в коде и написано:
util/support/fake-addrinfo.c:
     Upgrade host requirements to include working implementations of
     these functions, and throw all this away.  Pleeease?  :-)

Думаю нужно отключить эту обёртку - без неё всё и так работает. К сожалению, стандартных "ручек", для отключения, нет - оно прибито гвоздями:
#if (defined (__linux__) && defined(HAVE_GETADDRINFO)) || defined (_AIX)
/* See comments below.  */
#  define WRAP_GETADDRINFO
#endif

Ещё более огорчительно то, что это не единственная утечка памяти. Ещё одна имеет место быть при динамическом выделении контекста и, использовании методов для получения аутентификационных данных, в частности ключей из keytab функцией krb5_get_init_creds_keytab()

В общем с этим делом лучше, конечно в upstream... но хотелось бы утечку устранить, а не разработкой kerberos заняться... Проверки показывают, что отключение обёрток устраняет часть утечек, а вот чинить как это пока не понятно, да они и сами понимают, что эту часть кода нужно выкинуть...
Comment 1 Alexander Bokovoy 2009-04-10 18:10:42 MSD
Я не отвечаю за krb5, это к Сергею.
Comment 2 Ivan A. Melnikov 2018-11-16 22:53:34 MSK
Ещё актуально?
Comment 3 Anton Farygin 2018-12-05 15:23:04 MSK
Давно уже не актуально.