Как освобождается память от std::vector и std:map?

https://en.cppreference.com/w/cpp/container/vector/~vector

https://en.cppreference.com/w/cpp/container/map/~map

А какие у тебя варианты кроме «да, освобождается», и «нет, не освобождается, они намеренно спроектированы так чтобы память утекала»? Или про что вопрос? Нет, clear явно звать не нужно.

Спасибо - успокоили. А я как последний дебил в сотне мест добавлял arr.clear(); vector<ZFtaTreeGate*>().swap(arr);

Просто оказался в дикой ситуации, когда хватаешься за любую соломинку. Есть подозрение на утечку памяти - свое я все проверил, но проблема осталась, вот я и начал дуть на vector. Хотя, конечно, изначально мне такой бруд не мог прийти в голову.

Собственно проблема такая: Есть сервер, на нем бежит вебсервер, который вызывает динамически сишную ДЛЛ. При втором обращении ДЛЛ падает, выдавая сигментайшин. Я написал на Си головную программу, которая так же динамически вызывает туже ДЛЛ. Моя программа не падает даже после 50 вызовов ДЛЛ.

Что это может быть?

Деструкторы STL контейнеров освобождают память только из под объектов которые в них хранятся.

т.е. если был такой вектор std::vector<std::string> v{«ab», «cd»};

то все удалится без утечек

а если такой std::vector<std::string*> v { new std::string{«ab»}, new std::string{«cd»} };

то деструктор вектора вызовет деструкторы указателей, но не строк. Поэтому нужно будет сначала пройтись по элементам и вызвать вручную удаление, перед выходом из области видимости.

Что это может быть?

Телепаты в отпуске. Берешь любой инструмент для анализа динамических аллокаций (massif, heaptrack, …) и смотришь, куда уходит память

Можно перехватить SIGSEGF и вывести стек, хотя бы будет понятно где легло.

arr.clear(); vector<ZFtaTreeGate*>().swap(arr);

Если вектор владеет этими указателями, на них всё-таки нужно звать delete, иначе они утекут.

Есть подозрение на утечку памяти

От утечек памяти по SIGSEGV обычно не падают.

Что это может быть?

Что угодно. gdb, valgrind, санитайзеры в помощь.

Главное, что нужно знать – clear() память не освобождает. Только деструктор или shrink_to_fit() из C++11.

Что за вебсервер?
Сорцы длльки есть?

вот я и начал дуть

Прежде чем дуть, следовало ознакомиться с инструментами поиска утечек такими как, например, valgrind.

на нем бежит вебсервер, который вызывает динамически сишную ДЛЛ. При втором обращении ДЛЛ падает

про «может быть всё что угодно» уже выше написали :-) Но может быть повторная загрузка. .so/.dll плагином загрузилась, также выгрузилась, и при очерёдной загрузке всё свалилось

Совсем вовсе не все «сишные ДЛЛ» умеют в повторную загрузку.

В массе вообще делается что .so/.dll если уж загружены, то невыгружаются до завершения приложения, а это не так. Но на это как правило забивают болт

Прогони под валгриндом.

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

valgrind я уже использовал. Он молодец поймал меня на 2-х потерях. Но кроме моих потерь он отловил еще потери в стандавтной библиотеке. Потери маленькие и врядли могут дать такой тяжелый эффект. Все элементы, на которые ссылаются вектора я естесственно удаляю.

Про длл. А есть ли дейсвительно эффективный метод перезагрузить длл с освобождением ее памяти?

конечно. при выходе из блока вызываются деструкторы нетривиальных обьектов, определенных в блоке. они и освобождают ресурсы, в том числе и память. это делается явно в самих деструкторах.

это и есть одно из предназначений деструктора.

проверь в точности конвенции вызовов функций dll (какие использует dll, какие используешь ты, и какие на «сервере»)

Интернет мне мозги скрутил.

Отдохни от него.

Поэтому нужно будет<…>

Использовать умные указатели. Хватит сишкой обмазываться.

Мне сказали, что у линкера есть опция, которая заставляет систему полностью освобождать память из-под ДЛЛ после free. Но я не могу найти эту опцию.

Может быть кто-нибудь с ней знаком?

так спроси у того кто сказал