Сообщение Re[6]: Докладываю от 16.09.2021 5:19
Изменено 16.09.2021 5:34 AlexGin
Re[6]: Докладываю
Здравствуйте, Marty, Вы писали:
M>Ну это не про логи. Мне лень было делать МВП, поэтому я свалил на QCustomPlot
M>Несомненно, проблема была в моём приложении. Только я не понял, где
Я бы — попробовал разобраться в чём проблема. Обычно потом вылезает в самый неподходящий момент.
При этом, совсем не обязательно отказаться от применения QCustomPlot.
Просто определиться, что именно мешало применению Qwt.
M>Тут подумалось, что проблема могла быть в том, что я собрал DLLку как-то не так. Хотя, примеры из QWT я с ней собрал, и они работают. Если есть желание/настроение, можешь попробовать мою сборку и глянуть мои батники для сборки.
Хорошо, сбрось исходники и всё остальное (лучше — ссылочку на GitHub).
Попробую хоть чем-то помочь.
Сбрось на почту:
alexgin1965@gmail.com или же: alexgin1965@mail.ru
AG>>3) Да, крайний случай через логирование. Выводим в лог-файл значение переменных (например — указатель, чтобы знать что он НЕ нулевой).
M>Смысл? До вызова метода я нормально ставил бряк и в отладчике все указатели и пр внимательно проверял.
На выделенное выще ты тратил огромное время (с точки зрения программного процесса).
Уточню — время основного, или как ещё называют интерфейсного потока выполнения — aka main-thread.
А что же в это время делел, например рабочий поток (aka worker-thread), о котором ты забыл во время отладки?
Может этот worker-thread, не найдя свежих данных (из-за задержки main-thread), грохнулся об nullptr?
В наших разработках — такое бывает нередко. Вот тут на помощь приходит отладка логированием.
M>Ну это не про логи. Мне лень было делать МВП, поэтому я свалил на QCustomPlot
M>Несомненно, проблема была в моём приложении. Только я не понял, где
Я бы — попробовал разобраться в чём проблема. Обычно потом вылезает в самый неподходящий момент.
При этом, совсем не обязательно отказаться от применения QCustomPlot.
Просто определиться, что именно мешало применению Qwt.
M>Тут подумалось, что проблема могла быть в том, что я собрал DLLку как-то не так. Хотя, примеры из QWT я с ней собрал, и они работают. Если есть желание/настроение, можешь попробовать мою сборку и глянуть мои батники для сборки.
Хорошо, сбрось исходники и всё остальное (лучше — ссылочку на GitHub).
Попробую хоть чем-то помочь.
Сбрось на почту:
alexgin1965@gmail.com или же: alexgin1965@mail.ru
AG>>3) Да, крайний случай через логирование. Выводим в лог-файл значение переменных (например — указатель, чтобы знать что он НЕ нулевой).
M>Смысл? До вызова метода я нормально ставил бряк и в отладчике все указатели и пр внимательно проверял.
На выделенное выще ты тратил огромное время (с точки зрения программного процесса).
Уточню — время основного, или как ещё называют интерфейсного потока выполнения — aka main-thread.
А что же в это время делел, например рабочий поток (aka worker-thread), о котором ты забыл во время отладки?
Может этот worker-thread, не найдя свежих данных (из-за задержки main-thread), грохнулся об nullptr?
В наших разработках — такое бывает нередко. Вот тут на помощь приходит отладка логированием.
Re[6]: Докладываю
Здравствуйте, Marty, Вы писали:
M>Ну это не про логи. Мне лень было делать МВП, поэтому я свалил на QCustomPlot
M>Несомненно, проблема была в моём приложении. Только я не понял, где
Я бы — попробовал разобраться в чём проблема. Обычно потом вылезает в самый неподходящий момент.
При этом, совсем не обязательно отказаться от применения QCustomPlot.
Просто определиться, что именно мешало применению Qwt.
M>Тут подумалось, что проблема могла быть в том, что я собрал DLLку как-то не так. Хотя, примеры из QWT я с ней собрал, и они работают. Если есть желание/настроение, можешь попробовать мою сборку и глянуть мои батники для сборки.
Хорошо, сбрось исходники и всё остальное (лучше — ссылочку на GitHub).
Попробую хоть чем-то помочь.
Сбрось на почту:
alexgin1965@gmail.com или же: alexgin1965@mail.ru
AG>>3) Да, крайний случай через логирование. Выводим в лог-файл значение переменных (например — указатель, чтобы знать что он НЕ нулевой).
M>Смысл? До вызова метода я нормально ставил бряк и в отладчике все указатели и пр внимательно проверял.
На выделенное выше ты тратил огромное время (с точки зрения программного процесса).
Уточню — время основного, или как ещё называют интерфейсного потока выполнения — aka main-thread.
А что же в это время делел, например рабочий поток (aka worker-thread), о котором ты забыл во время отладки?
Может этот worker-thread, не найдя свежих данных (из-за задержки main-thread), грохнулся об nullptr?
В наших разработках — такое бывает нередко. Вот тут на помощь приходит отладка логированием, тот же spdlog.
Тогда, логируюя переменные головного (main-thread) и вспомогательного (worker-thread) потоков,
выясняем эту проблему и, например, чиним синхронизацию потоков, чтобы worker-thread коррктно ждал.
Ну или что-либо другое, в зависимости от причины.
M>Ну это не про логи. Мне лень было делать МВП, поэтому я свалил на QCustomPlot
M>Несомненно, проблема была в моём приложении. Только я не понял, где
Я бы — попробовал разобраться в чём проблема. Обычно потом вылезает в самый неподходящий момент.
При этом, совсем не обязательно отказаться от применения QCustomPlot.
Просто определиться, что именно мешало применению Qwt.
M>Тут подумалось, что проблема могла быть в том, что я собрал DLLку как-то не так. Хотя, примеры из QWT я с ней собрал, и они работают. Если есть желание/настроение, можешь попробовать мою сборку и глянуть мои батники для сборки.
Хорошо, сбрось исходники и всё остальное (лучше — ссылочку на GitHub).
Попробую хоть чем-то помочь.
Сбрось на почту:
alexgin1965@gmail.com или же: alexgin1965@mail.ru
AG>>3) Да, крайний случай через логирование. Выводим в лог-файл значение переменных (например — указатель, чтобы знать что он НЕ нулевой).
M>Смысл? До вызова метода я нормально ставил бряк и в отладчике все указатели и пр внимательно проверял.
На выделенное выше ты тратил огромное время (с точки зрения программного процесса).
Уточню — время основного, или как ещё называют интерфейсного потока выполнения — aka main-thread.
А что же в это время делел, например рабочий поток (aka worker-thread), о котором ты забыл во время отладки?
Может этот worker-thread, не найдя свежих данных (из-за задержки main-thread), грохнулся об nullptr?
В наших разработках — такое бывает нередко. Вот тут на помощь приходит отладка логированием, тот же spdlog.
Тогда, логируюя переменные головного (main-thread) и вспомогательного (worker-thread) потоков,
выясняем эту проблему и, например, чиним синхронизацию потоков, чтобы worker-thread коррктно ждал.
Ну или что-либо другое, в зависимости от причины.