LINUX.ORG.RU

Нужен профайлер

 ,


0

1

Есть очень многопоточный софт на с++, с чудесными утечками памяти, чем их можно найти под дебианом?
Валгринд не может искать утечки в многопоточном, т.к. все потоки выполняет в одном, из-за чего до утечек даже дойти не успевает.
Желательно профайлер без необходимости ставить иксы хотя бы на сервере.

Валгринд не может искать утечки в многопоточном

Серьёзно? Okay

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

but Valgrind serialises execution so that only one (kernel) thread is running at a time

but it does mean that threaded apps never use more than one CPU simultaneously, even if you have a multiprocessor or multicore machine.

А прочитать свою ссылку никак? Я повторяю:

все потоки выполняет в одном, из-за чего до утечек даже дойти не успевает.

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

На хера её читать, я сам отлаживал многопоточное приложение, причём с memory pool'om. Из того, что ты процитировал никак не вытекает то, что ты написал, поэтому логики не вижу.

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

Запусти 4 потока с epoll_wait на 5 секунд и 1 поток с таймером каким-нить, например и удивись насколько таймер будет лагать. А у меня сетевой софт с 4-6 epoll_wait, до accept под валгриндом дошли немногие, не говоря про нормальную работу.

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

gprof однопоточный, тогда уж oprofiled использовать. Но он не для поиска утечек предназначен.

UVV ★★★★★ ()
Ответ на: комментарий от zlofenix

Стесняюсь спросить, зачем тебе таймер?

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

Я к тому, что он будет заметно тормозить и для примера же.

zlofenix ()
Ответ на: комментарий от i-rinat

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

zlofenix ()
Ответ на: комментарий от i-rinat

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

zlofenix ()

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

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от zlofenix

https://code.google.com/p/gperftools/
тебя будет интересовать:
http://gperftools.googlecode.com/git/doc/heap_checker.html

можно попробовать без перекомпиляции - нужно подключить в LD_PRELOAD их реализацию менеджера памяти.

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

art_corp ()
Последнее исправление: art_corp (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Попробовал им, минуты не прошло, а лог уже к 100 мегам подползает, винты треснут раньше.

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

Уже много раз так делал, там из 2х больших кусков сшито и в каком из них проблема - не знаю.

zlofenix ()

Попробую подойди с другой стороны и взгляни на код глазами cppcheck.

UVV ★★★★★ ()
Ответ на: комментарий от zlofenix

100 МБ в минуту это всего 140 ГБ за сутки. Не так уж и много.

i-rinat ★★★★★ ()
Ответ на: комментарий от zlofenix

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

  HeapLeakChecker heap_checker("test_foo");
  {
    code that exercises some foo functionality;
    this code should not leak memory;
  }
  if (!heap_checker.NoLeaks()) assert(NULL == "heap memory leak");
Note that adding in the HeapLeakChecker object merely instruments the code for leak-checking. To actually turn on this leak-checking on a particular run of the executable, you must still run with the heap-checker turned on:

% env HEAPCHECK=local /usr/local/bin/my_binary_compiled_with_tcmalloc

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

Так яж не tmalloc пробовал, а mtrace, до гуглотулз еще не добрался.

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

cppcheck - это статический анализатор кода, найти динамические ошибки с ним нельзя.
Если только вида:

int* a = new int[n];
delete a;
a = malloc(sizeof(int)*100);
delete a;
и т.п.

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

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

Т.е. ждать сутки не потребуется.

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

Там, где это возможно - утечка памяти весьма не большая, но может с 1-10 попытки уронить софт, зато запросы известны и так, но раньше 1х суток оно не происходит. А где невозможно - там утечка тоже не думаю что большая, т.к. работает стабильно сутками, при дофига утечек, но отследить запрос невозможно.

zlofenix ()

http://www.drmemory.org/ - аналог valgrind, обещающий лучшую производительность.

Не могу сказать что он удобен, однако с версией 1.4 провести минимальный анализ источников утечек мне вполне удалось. (правда на windows32, но вроде linux32 он поддерживает не хуже)

GPFault ★★ ()
Ответ на: комментарий от zlofenix

Там, где это возможно - утечка памяти весьма не большая, но может с 1-10 попытки уронить софт


это уже не утечка, а порча памяти. Нужно смотреть не инициализированные переменные, запись/чтение за границы массивов.

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

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

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

Спасибо, возможно попробую, просто софт х64, а он требует х323 либы, хотя и не факт что вообще может в х64.

zlofenix ()

с чудесными утечками памяти

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

but Valgrind serialises execution so that only one (kernel) thread is running at a time

but it does mean that threaded apps never use more than one CPU simultaneously, even if you have a multiprocessor or multicore machine.

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

Что касается утечек памяти, то тут профайлер вообще не нужен.

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

появляются мертвые сокеты

оберни свои сокеты в класс, который помнит, где и кем данный сокет был создан, и что с ним потом происходило.

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

Память выделяю через new класс, больше незачем.
Просто одно ядро не справляется со всеми потоками из-за задержек и wait'ов в них.
Тогда память закончится раньше, чем всплывет ошибка, т.к. сокеты весьма быстро закрываются и рождаются новые.

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

Память выделяю через new класс, больше незачем.

ну ты ССЗБ(точнее автор кода). У тебя там всё на указателях, а это АдЪ.

Обычно память выделяется внутри класса. Т.е. в коде ты пишешь

Matrix A(3,3);

а память под матрицу выделяется примерно так:

Matrix::Matrix(int y, int x)
{
  ptr = new[x*y];
}
ну а освобождается в деструкторе.

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

Тогда можно:

Matrix A(3,3);
Matrix B(A); // или Matrix B=A;
Matrix C;
C = A;

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

А чаровские строки у вас, случаем, не используются? Похоже на выход за границы массива.

four_str_sam ()

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

EugeneBas ★★ ()
Ответ на: комментарий от UVV

никто про perf стандартный линуксовый не вспомнил... он не умеет утечки ловить?

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от emulek

Не, в классах обычные переменный. Указательного ада нет, указатели вообще в 3.5 местах и сама карта сокетов. Рукотворных массивов нет вообще.

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

Нет. Ну и выход за границы сразу в кору упал бы и весьма явно.

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

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

zlofenix ()
Ответ на: комментарий от I-Love-Microsoft

Ищет use after free, buffer overflow и прочее. В свежих версиях еще и утечки показывает. Отдельными опциями есть data race детектор и UB.

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

Вот только купить на торентах не композер версию, с инспектором - проблема.

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

Легко. Я и gcc и clang собираю.

cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

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