Для начала попробовать версию отсюда: https://www.qt.io/download-open-source

А пишет оно случайно не в пайп, из которого не читают?

Тогда бы не было стек-трейса, по идее.

нет, я никуда не перенаправлял

Для начала попробовать версию отсюда

Я бы поостерёгся с такого начинать и тем более советовать. Да, теоретически есть вероятность, что проблема в Qt, но всё же гораздо вероятнее, что в самой программе проблема, которая просто раньше не проявлялась.

Я бы всё-таки сначала погонял всякие проверки, помахал valgrind-ом и др. И уже если ничего не помогает - начал бы щупать версии Qt.

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

Я бы ещё посмотрел, не являются ли передаваемые в qDebug строки объектами, которые уже как-то испорчены. В этом случае и qDebug может вызвать зависание, разумеется.

Так ничего не падает, это из отладчика трейс.

И он был бы как раз таким, пока поток спит, ожидая освобождения места. Я потому и спросил, так как понял, что висит в ядре.

Убрать qDebug в том месте не проблема - он там больше не нужен. Мне хочется разобраться почему он вызывает зависание. в qdebug такое:

qDebug("[Class::function]: %jd/%d", (intmax_t)qint64_variable, bool_variable);

qDebug(«[Class::function]: %jd/%d», (intmax_t)qint64_variable, bool_variable);

%d

bool_variable

Как минимум одна проблема найдена, попытка прочитать 32-битный int за пределами булевой переменной. Не уверен, что это и есть причина зависаний, я бы открыл в отладчике и посмотрел во что сформировалась строка, возможно она не заканчивается нулём. Также можно собрать Qt самому в режимах debug и release, проверить повторяемость, по крайней мере на шаг к причине проблемы станет ближе.

попытка прочитать 32-битный int за пределами булевой переменной

А разве здесь числовые типы меньшие int не приводятся в тип int (как в функциях семейства printf)?

Нет, это не проблема. Но попробуй переписать так:

qDebug() << "[Class::function]:" << qint64_variable << bool_variable;

А разве здесь числовые типы меньшие int не приводятся в тип int (как в функциях семейства printf)?

Приводить или нет может решить только компилятор на основании всякой эвристики, такой как атрибуты функций и строка форматирования, известная на этапе компиляции. Это нестандарт и в общем случае не работает.

Да ты шо.
http://stackoverflow.com/questions/2725044/can-i-assume-booltrue-int1-for-any...

Integral promotion applies and the bool value will be promoted to an int and this promotion must yield 1.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf

If the destination type is bool, see 4.12. If the source type is bool, the value false is converted to zero and

the value true is converted to one.

У меня такой вопрос. Программа собиралась тем же самым компилятором, с теми же настройками, что и библиотека Qt?

А разве здесь числовые типы меньшие int не приводятся в тип int (как в функциях семейства printf)?

Перечитал ещё раз документацию, всё верно, интегральные типы размером меньше int приводятся к int во всех variadic-функциях.

Ты путаешь статическое приведение с правилами приведения для функций с переменным количеством аргументов.

Завиcание на qDebug (комментарий)

Ты путаешься в показаниях

Программа собиралась тем же самым компилятором, с теми же настройками, что и библиотека Qt?

Минутку, разве в Linux это важно? Я слышал что это проблема оффтопика, но никак не Linux. Или я что-то упустил?

Автор темы так и не попробовал qDebug() <<

Могу ещё раз повторить, что ты путаешь статическое приведение с правилами приведения для функций с переменным количеством аргументов. Твои ссылки выше к теме не имеют отношения.

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

Чтоб падало на qDebug - вангую что сбой памяти где то в другом месте. НИКОГДА не видел чтобы падало на вызове qDebug, поэтому с большой долей вероятности предполагаю проблемы с памятью - где-то затаилась ошибка.

Да, проведи memtest компа где падало.

Еще - бывает надо собрать проект начисто и падения прекратятся, есть такая проблемка.

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

Приложение однопоточное? Хендлер для qDebug не переопределялся?

многопоточное. не переопределялся. висло в главном потоке

Возможно, это косяк в докере

Я недавно столкнулся абсолютно с такой же проблемой. Наработка на отказ - 10-30 минут. Программа интенсивно писала логи в консоль.

После того, как это же наигралось на невинном

cat /dev/urandom | hexdump

В родительской ОС не наигрывалось, а вот в докере - в лучшем виде.

Товарищи расследовали это дело, и вот что у них вышло:

https://github.com/containerd/console/pull/27

да, сам баг в трекере докера: https://github.com/docker/for-linux/issues/353