Russian Qt Forum
Ноябрь 24, 2024, 14:49 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: free(): invalid next size (fast)  (Прочитано 6831 раз)
vulko
Гость
« : Ноябрь 12, 2014, 14:32 »

Ребята, столкнулся с таким вот крэшем.
То ли double free, то ли free/new, то ли delete/malloc...

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

Что это, баг Qt? Куда копать? Дебажить внутри Qt?
Я верно понимаю мне нужно будет пересобрать Qt в дебажную версию?
Умеет ли QtCreator дебажить внутри .so?

Qt предустановлен в пакетах уже, можно ли без пересборки? Может подтянуть пакет откуда? Или побилдить дебажные либы и подменить ими обычные?

Qt 4.8.5
Linux (X Windows) дебианоподобное.

Цитировать
0   __GI_raise   raise.c   64   0x7ffff519dbf5   
1   __GI_abort   abort.c   92   0x7ffff51a0d98   
2   __libc_message   libc_fatal.c   189   0x7ffff51d7d15   
3   malloc_printerr   malloc.c   6283   0x7ffff51e1dc6   
4   __GI___libc_free   malloc.c   3738   0x7ffff51e5d7c   
5   QBoxLayout::setGeometry(QRect const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b174fb   
6   QLayoutPrivate::doResize(QSize const&)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b31c73   
7   QLayout::activate()   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b331bd   
8   QApplicationPrivate::notify_helper(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0916e   
9   QApplication::notify(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6b0d62a   
10   QCoreApplication::notifyInternal(QObject*, QEvent*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62906be   
11   QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62947a1   
12   ??   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bee03   
13   g_main_context_dispatch   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49355   
14   ??   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49688   
15   g_main_context_iteration   /lib/x86_64-linux-gnu/libglib-2.0.so.0   0   0x7ffff3a49744   
16   QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff62bef96   
17   ??   /usr/lib/x86_64-linux-gnu/libQtGui.so.4   0   0x7ffff6baf0de   
18   QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f40f   
19   QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff628f698   
20   QCoreApplication::exec()   /usr/lib/x86_64-linux-gnu/libQtCore.so.4   0   0x7ffff6294ab8   
21   main   main.cpp   23   0x417ecd   
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #1 : Ноябрь 12, 2014, 15:05 »

В 99.9% случаев это твоя ошибка при работе с указателями - двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg
« Последнее редактирование: Ноябрь 12, 2014, 15:08 от Alex Custov » Записан
vulko
Гость
« Ответ #2 : Ноябрь 12, 2014, 15:20 »

В 99.9% случаев это твоя ошибка при работе с указателями - двойное удаление, разыменование нулевого указателя и т.п. Ищи ошибку у себя в коде. Можно с помощью valgrind, но лучше руками.

Debug символы можно получить установив пакет qtbase5-dbg

Ты стэк смотрел? Там ниодного моего вызова нет)
Хотя не отрицаю, что мой код мог спровоцировать подобное поведение...
Либо creator как обычно криво дебажит... но уж стэк то не должен был перепутать.

valgrind я бы и рад, но с ним нереально будет воспроизвести ошибку вообще никак. я вижу дикое слайдшоу под валгриндом.
впрочем можно попробовать перерисовку делать не раз в 10мс а раз в 1секунду... надо попробовать. но это уже не то.
да и он мне очень много ошибок выдает, но 99% внутри qt, llvm и другой шляпы...

пакет попробую канеш, но у меня гемор с дебиановским и убунтовским репозиториями. т.к. линух "кастомный".
отдельно можно его где нибудь скачать и поставить ручками?
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #3 : Ноябрь 12, 2014, 15:32 »

Ты стэк смотрел? Там ниодного моего вызова нет)

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

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

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.
Записан
vulko
Гость
« Ответ #4 : Ноябрь 12, 2014, 15:44 »

Ты стэк смотрел? Там ниодного моего вызова нет)

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

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

Из репозиториев твоего дистрибутива. Ставить откуда-то ещё крайне не рекомендуется.

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

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

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc'ом, то крэш не был бы рандомным наверное?
впрочем это я проверю все же...
Записан
Alex Custov
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2063


Просмотр профиля
« Ответ #5 : Ноябрь 12, 2014, 20:30 »

если бы это была проблема double free или free памяти выделенной new или delete памяти выделенной malloc'ом, то крэш не был бы рандомным наверное?

Поведение в такой ситуации не определено, и поэтому может быть любым.
Записан
vulko
Гость
« Ответ #6 : Ноябрь 24, 2014, 12:31 »

Никаких double free, как я и предполагал нет.
Лики были, пофиксил.

Не понимаю причину крэша... Хотя возможно было как-то связано с тем что я хранил ссылки на QObject в модели... Эти же QObject'ы жили в QTableWidget, который очищался при очистке модели... правда они без parent'а были, поэтому при очистке таблицы они не удалялись...

В общем так и не понял я причину...
Записан
Bepec
Гость
« Ответ #7 : Ноябрь 24, 2014, 12:40 »

Указатели new delete освобождение.
 Вот если б твоё приложение логировало полностью своё поеведение вплоть до занимаемых и очищаемых секторов памяти, тогда б ты мог уверенно сказать про причину Улыбающийся А так раз на раз не приходится Веселый
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.052 секунд. Запросов: 23.