Утечка памяти?

ну походу, где-то в недрах *view указатель запоминается и валгринд думает что утечек нет.

Попробуй так

    QSplitter *splitter = new QSplitter;
    -splitter->addWidget(tree);
    splitter->addWidget(list);
    splitter->addWidget(table);
    splitter->show();

что-то не так, утечки он обнаруживает, но почему-то он их определяет как внешние http://ompldr.org/vZHExeg .

А у меня оно так выглядит:

==9853== 168 bytes in 1 blocks are possibly lost in loss record 4,778 of 5,530
==9853==    at 0x4024986: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==9853==    by 0x4010F6B: _dl_allocate_tls (dl-tls.c:300)
==9853==    by 0x4D8E5A0: pthread_create@@GLIBC_2.1 (allocatestack.c:580)
==9853==    by 0x4B54FE7: QThread::start(QThread::Priority) (in /usr/lib/libQtCore.so.4.7.4)
==9853==    by 0x46FE40B: ??? (in /usr/lib/libQtGui.so.4.7.4)
==9853==    by 0x46F4A1E: QFileSystemModel::QFileSystemModel(QObject*) (in /usr/lib/libQtGui.so.4.7.4)
==9853==    by 0xBEB98307: ???

С флагом -ggdb собирали?

.pro: CONFIG = debug

Без отладочной информации у меня отображается так:

...
==6463==    by 0x400CF4: main (in /home/andrew/leak/leak)
...

Может какие-то магические вещи вроде SeLinux, AppArmor что-то натворили?

ОС удаляет память, выделенную приложением, при завершении работы приложения. IMHO, поскольку модель создавалась один раз и более не удалялась/пересоздавалась, поэтому possibly lost.

По этому я не переживаю и я понял, инетересует почему эта ошибка попадает в список учетек вне моего приложения? Ошибки вроде int *ptr = new int; отлавливаются нормально

У меня в дебиане по умолчанию такого нет. Замена -g на -ggdb ничего не меняет.

А как это внешние? Я valgrind только из ком. строки использую. И без QtCreator. Так если источник main.c - то это как раз мои «внутренние» ошибки. В данном случае он даже не отследил строку. Но в вашем случае как раз нашёл.

Кстати, если сравнить конкретно, как вызывается g++:

g++ -c -pipe -g -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o qt_model_valgrind.o qt_model_valgrind.cpp
g++  -o qt_model_valgrind qt_model_valgrind.o    -L/usr/lib -lQtGui -lQtCore -lpthread 

Внешние - это которые произошли(или возможно произошли) в Qt4, libpng, glib и других библиотеках. Как можно было заметить по скроллбару на моем скриншоте( http://ompldr.org/vZHExeg ) их очень много и мои утечки легко теряются среди них. Qt Creator есть возможность скрыть все ошибки, кроме тех, которые происходят внутри моего кода.

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

бро, объясни, как ты дожил до такого, что в один процесс и куты и глиб линкуешь?

qmake -project
qmake
make
valgrind ./leak

http://labs.qt.nokia.com/2006/02/24/qt-and-glib/

бро, объясни, как ты дожил до такого, что в один процесс и куты и глиб линкуешь?

Qt уже сто лет поддерживает glib event loop.

Может имелось ввиду зачем так делать, а не сама метода обїединения двух библиотек?

По умолчанию делается, вроде бы чтобы работали gtk-темы. Или если кому взбредет gobject либы с Qt использовать, чтобы у них glib-loop тоже был.

вот собственно меня интересует, например, вопрос чего нет в Qt,но есть в gobject , ведь как иначе объяснить действия ТС?

glib линкуется по-умолчанию, если при сборке Qt'а флагом не отключить. По крайней мере в Archlinux пакет qt зависит от glib2.

вот собственно меня интересует, например, вопрос чего нет в Qt,но есть в gobject

Библиотеки. Иногда в Qt-приложении приходится использовать C-библиотеки, использующие glib.

Уяснил, спасибо