LINUX.ORG.RU

ААА!!! STL делает Leakи! Катастрофа! Что делать???


0

0

Несколькими строчками ниже (в форуме) я задавал вопрос как обнаружить leaks в программе. Смотрите Сэмпл:

#include <mcheck.h>
#include <string>

void main() {
mtrace();
std::string string;
string = "hello";
muntrace();
}
Потом запускаю эту прогу, предварительно установив переменную MALLOC_TRACE=sample.mem, чтобы в этот файл писалась инфа о ликах. Потом запускаю
mtrace sample.mem
Показывает лик в 500h байт! Причем если убрать string = "hello", то лика не будет. Да у меня в прогах сотни подобных присваиваний. Это же катастрофа всего человечеста. HELP!!!!!!!!!!!!!!!!!!!!
g++ не освобождает память. Я также пробовал new и delete, чтоб после muntrace стек был чистый - все равно!!!!!!!!!

anonymous

memory leaks

Память твою забрал, по всей видимости, allocator и не отдаёт, потому что думает, что ещё пригодится. Ничего страшного. Если сделаешь вот так:
mtrace ();
{
std::string string1 = "Hello";
}
{
std::string string2 = "Goodbye";
}
muntrace ();

то увидишь, что память выделялась только один раз, а не два, так что никакой утечки нет.

justme
()

Кстати, ты получил бы то же самое в любой реализации.
Ты выделяешь память после включения mtrace(),
и ВЫКЛЮЧАЕШЬ трассировку ДО вызова деструктора.
Вообще убери muntrace (), он не нужен, если целиком программу гоняешь.

Да, при этом лик не исчезнет, см. комментарий
justme (*) (2002-02-19 21:51:33.0)
(и заодно обрати внимания, как у него расположены блоки).

Die-Hard ★★★★★
()

Дело в том, что деструктор string всё равно не отдаёт память. То есть, string отдаёт память allocator'у, но allocator её не отдаёт дальше, поэтому этого не видно в mtrace.

Странно, правда, что allocator память не возвращает в *своём* деструкторе (если убрать muntrace, то всё равно не видно вызова free).

justme
()
Ответ на: комментарий от justme

2justme (*) (2002-02-19 23:04:28.0):
> Странно, правда, что allocator память не возвращает в *своём* деструкторе
> (если убрать muntrace, то всё равно не видно вызова free)
Да, я тоже заметил.

IMHO, это - баг (некритичный). Ну, дак не обязательно ж память освобождать -
все равно освободится, когда задача окончится.

Вообще, g++ с либами пока сыроват. И, боюсь, таким и останется.

Die-Hard ★★★★★
()

2anonymous (*) (2002-02-19 21:22:39.0):
Кстати, на будущее, совет:
если найдешь лик, не думай сразу, что это - лик :)
Прогони подозрительный кусок в бесконечном цикле, и смотри при этом на память.

Даже такой прием не всегда помогает, иногда память освобождается
только при определенных условиях, которые в реальности встречаются часто, а ты
в своей тестовой (нефункциональной!) программе их обошел.

Например, память может освобождать обработчик событий, а ты в тестовой программе
заводил/удалял объекты в цикле, не давая шанса произойти событию.

Die-Hard ★★★★★
()

А можт написать ребятам, которые делают g++. Ведь такой простой примерчик! Неужели они не сделают маленький фиксик. :) Все таки в такой ОС как Linux такие баги - удар в грязь лицом.

anonymous
()
Ответ на: комментарий от anonymous

2:anonymous (*) (2002-02-20 03:30:33.0)

Тебе же уже объяснили, что это не баг вовсе. Это фича :))

asd
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.