отладка приложения , отладчик он нужен или нет?

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

The program has unexpectedly finished.

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

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(this)
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    qDebug() << "mCpuWidget: " << &mCpuWidget;
    ui->centralWidget->layout()->addWidget(&mCpuWidget); //<-- видимо тут что то не так
}

Прикреплённый файлSysinfo.zip (7,69 Кбайт, скачиваний: 87)

пс. Проект на Qt Creator 4.2 + Qt 5.7 + MinGW 5.3 + Win10.

Сообщение отредактировано: Cfon - 20.02.17, 12:00

Цитата Cfon @ 20.02.17, 11:51

ui->centralWidget->layout()->addWidget(&mCpuWidget); //<-- видимо тут что то не так

А у тебя там nullptr что-нибудь не возвращает, в этой цепочке?

Цитата Олег М @ 20.02.17, 12:10

А у тебя там nullptr что-нибудь не возвращает, в этой цепочке?

нет ui инициализирован, mCpuWidget тоже создается.
centralWidget->layout()->addWidget() это хозяйтво уже Qt, что там происходит я не знаю

Сообщение отредактировано: Cfon - 20.02.17, 13:00

Попроуй сделать mCpuWidget указателем.
Вообще, создавать QObject на стеке, передавая ему указатель на родителя - верный способ нарваться на весёлые грабли

Цитата OpenGL @ 20.02.17, 13:10

Попроуй сделать mCpuWidget указателем.
Вообще, создавать QObject на стеке, передавая ему указатель на родителя - верный способ нарваться на весёлые грабли

спс позже проверю , пока решил по другому:

MainWindow::MainWindow(QWidget  *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(this)
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    qDebug() << "mCpuWidget: " << &mCpuWidget;
    //ui->centralWidget->layout()->addWidget(&mCpuWidget);
    setCentralWidget(&mCpuWidget); //<-- вот так все пучком
    qDebug() << ui->centralWidget->layout();
}

я не силен пока в Qt что там не так с layout() вроде как возвращает null.

Сообщение отредактировано: Cfon - 20.02.17, 13:17

Может быть там перед вызовом layout Нужно вызвать addlayout ? Хотя я в qt тоже не силен, так чисто, предположение.

Цитата KILLER @ 20.02.17, 13:30

Может быть там перед вызовом layout Нужно вызвать addlayout ? Хотя я в qt тоже не силен, так чисто, предположение.

да все верно в centralWidget не был задан layout исправил теперь все пучком
также исправил создание CpuWidget указатель :

MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
    , mCpuWidget(new CpuWidget(this))
{
    qDebug() << "ctor MainWindow";
    ui->setupUi(this);
    SysInfo::instance().init();
    QLayout* layout = ui->centralWidget->layout();
    Q_ASSERT(layout);
    layout->addWidget(mCpuWidget);
}

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

баг обнаружил без отладчика своими проверенными методами ассерт + трассировка

Сообщение отредактировано: Cfon - 20.02.17, 16:14

Цитата KILLER @ 20.02.17, 09:22

Добавлено 20.02.17, 09:40
Вы еще приведите в пример - а как релизную сборку отлаживать отладчиком

Именно этот пример я и забыл привести.
Когда мы отлаживаем конкретную сборку, мы отлаживаем именно её.
Не факт, что в релизе всё останется так-же.
Тогда придётся отлаживать обе сборки, а зачем это делать, если достаточно одной ?
---
Можно взглянуть на проблему с совершенно неожиданной стороны.
Разницы между отладкой софта и хардвера принципиально нет никакой.
Разница в инструментах измерения.
"На вход" подаётся некий сигнал, "на выходе" ожидаем конкретный результат.
А он не совпадает с ожидаемым.
Начинаем производить измерения в промежуточных точках и находим проблему.
Совет "использовать при наладке дибаггерную сборку" выглядит просто дико - это
означает паять и налаживать другую схему, в надежде, что основная заработает так-же.

Сообщение отредактировано: ЫукпШ - 20.02.17, 20:40

Так в релизе выставляешь - генерировать дебаг инфу, и профит.

Добавлено 20.02.17, 20:39
Можно еще оптимизацию и скорость отключить.

Цитата KILLER @ 20.02.17, 20:39

Так в релизе выставляешь - генерировать дебаг инфу, и профит.

Добавлено 20.02.17, 20:39
Можно еще оптимизацию и скорость отключить.

А в проге баг, который проявляется при изменении размеров приложения
и при изменении расположения различных его частей в памяти...
---
Любое измерение тем ближе к истине, чем меньше искажений вносит оно в объект.
При таком рассмотрении вопроса предложение остановить программу (в точке останова)
и поизучать её кишки выглядит просто глупо.

Сообщение отредактировано: ЫукпШ - 20.02.17, 20:46

Цитата ЫукпШ @ 20.02.17, 20:34

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

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

Добавлено 20.02.17, 20:45

Цитата ЫукпШ @ 20.02.17, 20:42

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

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

Добавлено 20.02.17, 20:47

Цитата ЫукпШ @ 20.02.17, 20:42

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

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

Сообщение отредактировано: KILLER - 20.02.17, 20:47

Цитата KILLER @ 20.02.17, 20:44

Добавлено 20.02.17, 20:45

Цитата ЫукпШ @ 20.02.17, 20:42

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

Берешь ставишь брекпоинт с условием, в котором пишешь "при изменении размеров" и попадаешь на него только тогда, когда у тебя размеры окна изменятся.

Понеслась...
Да не размеры окна.
Размеры самого приложения. Физический размер exe-файла.
---
Бесполезный разговор.

Цитата ЫукпШ @ 20.02.17, 20:49

онеслась...
Да не размеры окна.
Размеры самого приложения. Физический размер exe-файла.
---
Бесполезный разговор.

Значит ты привел самый бредовый пример, который только смог выдумать. Который написан через жопу, и в котором тебе не только дебаг, но еще и трейсы толком не помогут. Я даже не могу себе представить случай, когда нужно увеличивать размер exe во время его выполнения. Вирус чтоль какой то? Ну бредовый ведь пример, мой с фокусом и то реалистичней. А это, вымысел какой то. И причем тут дебагер? Раз я не могу отладить случай, когда появился баг, мать его во время увеличения размера программы, значит дебагер бесполезен? Или что ты хотел донести? Тут как бы при прочих равных - я под отладчиком найду багу за 2 часа, ты с трейсами потратишь 2 дня. Вот и все разница. Это плюс ко всему, что обычно и начинают курить с логов. А если логи ничего путного не сказали, то тогда начинается углубленный анализ проблемы с использованием отладчика.
Никогда твои трейсы тебе не помогут, если у тебя какой нибудь access violation необработанный, и программа с пришибленной логикой, и не просто на 10 классов поделка, а серьезная, с кучей сценариев поведения. То что ты будешь делать трейсами - увижу за 10 минут под отладчиком, найду место где падает и буду решать проблему. В то время как ты будешь пихать свои трейсы куда не попадя, с целью хотя бы локализировать место. Вот и вся разница между трейсами и отладкой.

Добавлено 21.02.17, 05:33

Цитата ЫукпШ @ 20.02.17, 20:34

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

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

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

Сообщение отредактировано: KILLER - 21.02.17, 05:33

Цитата Cfon @ 20.02.17, 16:03

баг обнаружил без отладчика своими проверенными методами ассерт + трассировка

Ты нашёл ошибку не "своими методами", а исключительно потому, что разбил эту цепочку. Если бы ты запустил это под отладчиком, он бы сразу отловил исключение в нужной строке, безо всяких трассировок.
Не нужно все выражения пихать в одну строку - тяжело как отлаживать, так и читать.

В борьбе с багами все средства хороши.

Логи обычно помогают поймать и понять ошибке в логике и бизнес-логике. Особенно когда поведение внешнего интерфейса отличается от ожидаемого. А также внутренние ошибки логики. Отладчик напротив помогает бороться с аварийными ситуациями(access violation) и исключениями.
А вот проверка данных по входу делает программу устойчивой к ошибкам. Попутно это первый шаг к логам.
Статический анализ позволяет исключить описки и устранить забывчивость программиста. Так же тут помогают генераторы кода.
А вот тестирование. Воздействие и получение результата, влияет разом на все виды ошибок. Но основная суть её в фазинге. Зайти в те ветки условий в которые программа редко попадает. А метод чёрного ящика нацелен на поиск тех веток которых ещё и нет в программе, но они должны быть.


Логи очень хорошо помогают. Но умение ими правильно пользоваться сравни искусству. Уж больно мудрёная у них форма существования. Так как не понятно по каким событиям запускать логирование, а по каким молчать.

Сообщение отредактировано: Pavia - 21.02.17, 06:43