Как найти в qt проекте утечку памяти ?

Похоже на неинициализированную память https://en.wikipedia.org/wiki/Magic_number_(programming)#cite_ref-Win32CRTDeb...

Да, но вопрос откуда это посреди работы кода. Этот указатель на старте инициализируется и дальше после его наполнения только читается прогой для анализа. В какой-то момент на анализе он вот так 0xcdcdcdcd становится, как бы поймать где это происходит. Заметил, что если убирать qDebug по коду, то падает значительно реже.

valgrind

QList<MyClass *> * mylist

Указатель на QList не нужен. Изучите основы C++.

Копай в сторону неинициализированной памяти. Вот пример кода, который выводит CDCDCDCD в MS Visual Studio

#include <iostream>
#include <memory>

struct A {
    int * p;
};

int main()
{
    auto * a = new A;
    std::cout << a->p << std::endl;
    return 0;
}

Согласен, что не нужен. Я QList * никогда сам не использовал. Но в этой проге через сигналы этот указатель посылается в кучу других классов для обработки. Видимо поэтому был выбран указатель на QList.

Также вопрос как правильно передавать QList без указателя в другой слот по значению или его адрес, если сделать без указателя объявление.

При передаче через сигнал тебе нужна копия или просто доступ к оригинальному объекту? Начни с этого. Ещё QList поддерживает implicit sharing.

Вообще-то доступ нужен, так как слот может добавлять в QList объекты.

слот может добавлять в QList объекты

Странная архитектура, ну да ладно. У тебя косяк с временем жизни объектов. Это нужно устранять, чтобы QList жил дольше объекта, в котором находится слот. Как костыль можно использовать не сырой указатель, а std::shared_ptr.

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

gdb -ex "help watch" -batch

А я правильно понимаю, что самое простое в этом чужом проекте убрать указатели в QList и сделать его просто объектом

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

Как костыль можно использовать не сырой указатель, а std::shared_ptr.

Тогда можно получить утечку памяти, только не как в названии темы, а настоящую

valgrind --tool=memcheck --leak-check=yes --track-origins=yes --leak-check=full --show-leak-kinds=all ./your_qt_app

либо

-fsanitize=address -fstack-protector-all -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak

LD_PRELOAD=/path/to/libasan.so ./your_qt_app

Для qmake можно просто

CONFIG+=sanitizer
CONFIG+=sanitize_address

В смысле, не нужен? Откуда такая уверенность? Может, он невладеющий?

советую начать с cppcheck по проекту, потом valgrind, да

по этому поводу документации не доверяйте: там в списке QString, например, который в действительности implicit sharing не поддерживает, во всяком случае, в версии 4.6, на которой я проверял

нет, т.к.

Вообще-то доступ нужен, так как слот может добавлять в QList объекты.

Так в 4.6 и не заявлялась такая фича, это фишка 5-й кути.