Утечки памяти после использования typeinfo::name()

Другое решение состоит в том, чтобы исправить основную проблему. На самом деле это не утечка памяти, а просто ложный отчет. Блокам памяти, выделенным для строк tyepinfo() и name(), назначается неправильный тип блока. Вероятно, не стоит «освобождать» эту память, так как ЭЛТ попытается освободить ее снова. Хорошей новостью является то, что это было наконец исправлено в VS2012 (_MSC_VER 1700+).

Поскольку это относится только к сборкам _DEBUG, следующее решение может быть более безопасным. Функцию _FixTypeInfoBlockUse() следует вызывать, как указано выше, непосредственно перед выходом из точки входа модуля (main, WinMain и т. д.).

#if defined(_DEBUG) && (_MSC_VER >= 1000 && _MSC_VER <= 1699)
//
// Debug memory block header:
//    o  Borrowed from the Microsoft CRT to fix the false "memory leak" report
//       when using typeinfo 'name' accessor in a _DEBUG build of the library.  
//
struct _CrtMemBlockHeader
   {
   struct _CrtMemBlockHeader * pBlockHeaderNext;
   struct _CrtMemBlockHeader * pBlockHeaderPrev;
   char *                      szFileName;
   int                         nLine;
   #ifdef _WIN64
   int                         nBlockUse;
   size_t                      nDataSize;
   #else
   size_t                      nDataSize;
   int                         nBlockUse;
   #endif
   long                        lRequest;
   unsigned char               gap[4];
   };

static void __cdecl _FixTypeInfoBlockUse(void)
   {
   __type_info_node* pNode = __type_info_root_node._Next;

   while(pNode != NULL)
      {
      __type_info_node* pNext = pNode->_Next;

      (((_CrtMemBlockHeader*)pNode) - 1)->nBlockUse = _CRT_BLOCK;

      if (pNode->_MemPtr != NULL)
         (((_CrtMemBlockHeader*)pNode->_MemPtr) - 1)->nBlockUse = _CRT_BLOCK;

      pNode = pNext;
      }
   }

#endif//defined(_DEBUG) && (_MSC_VER >= 1000 && _MSC_VER <= 1699)

Я только что наткнулся на эту проблему, пытаясь очистить журнал VLD. Да, это известная ошибка, которая исправлена ​​только в VC11. Он существует в предыдущих версиях MSVC, включая 2010. Эта ошибка возникает только при использовании MFC. Если вы используете MFC в качестве DLL вместо статической библиотеки, утечка памяти все равно будет существовать, но не будет обнаружена.

Имеется глобальный кеш type_info имён и он не очищается (отрывок из <typeinfo>):

struct __type_info_node {
    void *_MemPtr;
    __type_info_node* _Next;
};

extern __type_info_node __type_info_root_node;

Идея состоит в том, чтобы очистить этот кеш. Эта функция работает для меня:

#include <typeinfo>

void clear_type_info_cache()
{
   __type_info_node* & node = __type_info_root_node._Next;
   while(node)
   {
      if (node->_MemPtr)
      {
         delete node->_MemPtr;
      }
      __type_info_node* tempNode = node;
      node = node->_Next;
      delete tempNode;
   }
}

Позвоните clear_type_info_cache() перед выходом. Вы можете зарегистрировать его с помощью atexit

#include <cstdlib>

int WinMain(...)
{
   atexit(&clear_type_info_cache);
   ...
}

или вызовите его непосредственно перед выходом из WinMain

struct dummy_scope_exit
{
   typedef void (*Fun)();
   dummy_scope_exit(Fun f) : m_f(f) {}
   ~dummy_scope_exit() { m_f(); }
   Fun m_f;
};

int WinMain(...)
{
   dummy_scope_exit cleaner = &clear_type_info_cache;
   ...
}

Как указал Крис Партон в комментариях, это похоже на известная ошибка, по крайней мере, с той версией компилятора, которую я использую - обновление до VC11 устранило бы проблему, если бы я смог обновиться.

Попытка удалить вывод typeinfo::name() работает частично:

std::string getMessageName(void) const
{
    std::string typeStr(typeid(*this).name());
    delete (typeid(*this).name());
    return typeStr;
}

Однако все еще есть некоторые утечки памяти - я только что заметил, что раньше у меня было две утечки на вызов (возможно, из-за того, что классы находились внутри пространства имен?). Используя приведенную выше версию кода, это сократилось до одной утечки на вызов.

Еще одно решение, которое, по-видимому, работает, состоит в том, чтобы связать динамическую версию библиотек MFC (да, я использую MFC, не осуждайте меня), а не статическую версию.

VS хранит информацию о типе в односвязном списке. Заголовок этого списка доступен через непрозрачную структуру, доступную по имени __type_info_root_node. На самом деле это структура SLIST_HEADER.

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

#include <Windows.h>
#include <typeinfo>
#include <vld.h>

void ClearTypeinfoCache()
{
#ifdef _DEBUG
    while (auto entry = InterlockedPopEntrySList(reinterpret_cast<PSLIST_HEADER>(&__type_info_root_node)))
    {
        free(entry);
    }
#endif
}

int main()
{
    atexit(ClearTypeinfoCache);
    return 0;
}

Обновлено: VLD 2.5.1 не сообщает об утечках памяти в type_info::name() в VS2015 Update 3.