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

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

Серьёзно? Okay

address-sanitizer

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.

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

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

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

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

А под gcc 4.7 есть шансы его запустить?

gprof поковыряй

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

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

Увеличь все таймауты в 20 раз.

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

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

Почему нет? Вот здесь mironov_ivan замедлил софт, к исходникам которого у него доступа нет.

И, вообще говоря, тебе не профайлер нужен, а детектор утечек. Глянь на http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html

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

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

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

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

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

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

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

Но зато нашлось много чего и все это в polarssl, офигенно.

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

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

Интересная вещь, попробую.

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

  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

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

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

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

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

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

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

http://spinroot.com/spin/whatispin.html ?

Судя по https://gcc.gnu.org/gcc-4.8/changes.html только с 4.8.

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

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

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

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

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

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

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

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

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 и более, будут ошибки в определении _времени_.

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

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

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

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

Память выделяю через 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;

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

clang -fsanitize=address

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

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

clang -fsanitize=address

А что это штука делает?

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

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

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

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

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

С учетом cmake'а сложно перекатить на clang?

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

cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

И разумеется clang'а нет под gcc 4.7 в wheezy, не везет мне.