Comments 53
Отлично. И теперь дождаться бы для Maemo.
мне что-то подсказывает, что нового обновления для Маемо не будет :-) Будем ждать MeeGo с 4.7 на борту.
Qt радует все больше и больше. Правильным путем идут товарищи.
PS Ссылка на changelog уже работает.
PS Ссылка на changelog уже работает.
Интересно, поправили ли вопиющие баги (в частности, когда Qt падает при отрисовке компонента QScintilla) или опять придётся самому патчить, пересобирать и ждать, когда же они сподобятся раскачаться =\
Смотреть здесь: bugreports.qt.nokia.com/browse/QTBUG
Если нет, то сообщать туда же.
Видимо как-то так…
Если нет, то сообщать туда же.
Видимо как-то так…
QScintilla никакого отношения к Qt не имеет — это сторонний компонент.
Спасибо, я как бы в курсе. Но я так же умею читать core dump-ы. И когда core dump сообщает
#0 0x00393c7a in qDrawArrow(QPainter*, Qt::ArrowType, Qt::GUIStyle, bool, int, int, int, int, QPalette const&, bool) () from /usr/lib/libQtGui.so.4
#1 0x0791a3f5 in QsciScintilla::QsciScintilla(QWidget*) () from /usr/lib/libqscintilla2.so.5
…
то я начинаю подозревать, что валится именно в Qt.
#0 0x00393c7a in qDrawArrow(QPainter*, Qt::ArrowType, Qt::GUIStyle, bool, int, int, int, int, QPalette const&, bool) () from /usr/lib/libQtGui.so.4
#1 0x0791a3f5 in QsciScintilla::QsciScintilla(QWidget*) () from /usr/lib/libqscintilla2.so.5
…
то я начинаю подозревать, что валится именно в Qt.
это ни о чем не говорит. Если конструктор QsciScintilla например вызывает метод у неинициализированног класса qDrawArrow, то естественно выполенние упадет именно в методе класса qDrawArrow, так как он полезет к данным экземпляра класса (к this например) и нарвется на мусор.
Так что я вообще не уверен, что бага в Qt судя по этому вот дампу.
Так что я вообще не уверен, что бага в Qt судя по этому вот дампу.
Ну, начнём с того, что qDrawArrow — это не класс, а функция (отдельная, не метод класса), поэтому речь о «недоинициализации» не идёт. Далее отметим, что в Qt 4.6 (и младше) тот же самый код работал без каких-либо проблем, а краш появился при апгрейде Qt с 4.6 до 4.7. Будем предполагать дальше?
Код работал без проблем, не значит, что он правильно работал
я написал слово «например», но как еще один вариан, это может быть, НАПРИМЕР, вызван метод у передаваемого QPainter или еще чего.
Чтоб быть точно увереным нужно не дампы смотреть, а запустить с дебажными кутишными библиотеками и отладочную QScintilla и посмотреть кто есть кто. А гадать — это не инженерный подход.
Чтоб быть точно увереным нужно не дампы смотреть, а запустить с дебажными кутишными библиотеками и отладочную QScintilla и посмотреть кто есть кто. А гадать — это не инженерный подход.
НАПРИМЕР может быть всё, что угодно. Хоть повреждение памяти. В том числе и физическое.
Гадать, действительно — не инженерный подход. Вот только кто из нас больше «гадает» в этом треде — Вы или я?
Гадать, действительно — не инженерный подход. Вот только кто из нас больше «гадает» в этом треде — Вы или я?
Гадаете вы, у вас нет доказательств, что ошибка в Qt, только стек с именами функций, в которые могли быть переданы невалидные параметры. Чтобы не гадать, нужно взять отладочные символы и посмотреть что там с QPainter* в первую очередь.
Ну конечно, я. Это же я с дебаггером обнаружил, что «если конструктор QsciScintilla например вызывает метод у неинициализированног класса qDrawArrow, то естественно выполенние упадет именно в методе класса qDrawArrow, так как он полезет к данным экземпляра класса (к this например) и нарвется на мусор».
И фиксы к Qt 4.6 я тоже «гадательные» присылал. Которые потом вошли в 4.6.1, хотя были присланы за 3 недели до релиза 4.6.0. Видимо, ребята из Nokia тоже увлекаются эзотерикой и «гаданиями», только не так серьёзно, как я.
И фиксы к Qt 4.6 я тоже «гадательные» присылал. Которые потом вошли в 4.6.1, хотя были присланы за 3 недели до релиза 4.6.0. Видимо, ребята из Nokia тоже увлекаются эзотерикой и «гаданиями», только не так серьёзно, как я.
Ой, простите, забыл откомментировать:
>… только стек с именами функций, в которые могли быть переданы невалидные параметры
А валидация параметров — для лохов. Более того: настоящие мачо не просто не делают валидацию (сами проверяйте, чего передаёте), а делают так: сначала проверяют все параметры, чтобы у всех всё работало, а потом, в одном из релизов (не в каком-то там 0.3 или 0.4, а круче: в 4.6 или 4.7) р-р-раз — и убирают проверку. Чтоб сторонние девелоперы не расслаблялись и не теряли форму. Ну и мейнтейнеры дистрибутивов заодно, которые потом патчат сорцы при сборке, иначе ломается куева туча софта в дистрибутиве.
Вы ведь не подумайте чего плохого: я работаю с Qt с ранних 3-их версий и считаю, что это прекрасная библиотека в всех смыслах этого слова (лучшая в своём классе и даже в некоторых «смежных классах»). Но то, что стало с качеством кода и с самим подходом к разработке после того, как Нокия купила Троллтек, мне решительно не нравится.
>… только стек с именами функций, в которые могли быть переданы невалидные параметры
А валидация параметров — для лохов. Более того: настоящие мачо не просто не делают валидацию (сами проверяйте, чего передаёте), а делают так: сначала проверяют все параметры, чтобы у всех всё работало, а потом, в одном из релизов (не в каком-то там 0.3 или 0.4, а круче: в 4.6 или 4.7) р-р-раз — и убирают проверку. Чтоб сторонние девелоперы не расслаблялись и не теряли форму. Ну и мейнтейнеры дистрибутивов заодно, которые потом патчат сорцы при сборке, иначе ломается куева туча софта в дистрибутиве.
Вы ведь не подумайте чего плохого: я работаю с Qt с ранних 3-их версий и считаю, что это прекрасная библиотека в всех смыслах этого слова (лучшая в своём классе и даже в некоторых «смежных классах»). Но то, что стало с качеством кода и с самим подходом к разработке после того, как Нокия купила Троллтек, мне решительно не нравится.
qDrawArrow — недокументированная функция, во всяком случае в Assistant про неё ничего нету и в публичных хедерах она не упоминается. Она вполне может не валидировать входящие параметры, а полагаться на то, что они будут провалидированы тем, кто её вызывает. Её вообще могут переименовать в следующем релизе. Так что не надо тут про р-р-раз и убирают проверку, могли и функцию убрать, нечего пользоваться приватным недокументированным АПИ.
>… нечего пользоваться приватным недокументированным АПИ.
Конечно, нечего. Вот только никто и не пользуется: в сорцах QScintilla вызов данной функции (как и любой другой qDraw*) не встречается ни разу. А вот кто её вызывает и почему не валидирует входящие параметры (раз уж функция на это полагается) — хороший вопрос, правда? ;)
Конечно, нечего. Вот только никто и не пользуется: в сорцах QScintilla вызов данной функции (как и любой другой qDraw*) не встречается ни разу. А вот кто её вызывает и почему не валидирует входящие параметры (раз уж функция на это полагается) — хороший вопрос, правда? ;)
Хороший. Ну так надо взять отладчик, символы и сорцы и выяснить, кто виноват. В любом случае, то, чем мы с вами сейчас занимаемся — гадание на кофейной гуще. В условиях наличия исходников это даже как-то странно выглядит :)
Судя по трейсу qDrawArrow метод вызывается из конструктора QsciScintilla => либо у вас исходники от левой версии либы, либо левый трейс, либо косяки с логикой
Версия с левыми исходниками и левым трейсом понятна. Поясните, откуда следуют мои косяки с логикой. Есть ещё версия с настройками дебаггера, но она не такая интересная :)
В общем я покопался по сорцам, qDrawArrow вызывает qDraw[Win|Motif]Arrow, которая таки не валидирует QPainter* p. Но она вообще помечена как QT3_SUPPORT и давным давно задепрекейчена. Ну и вообще, кому может прийти в голову рисовать непроинициализированным пеинтером?
А если вы напишете где-то у себя в коде memcpy(0, 0, 10000); и увидите в 0 фрейме memcpy, вы начнете подозревать, что ошибка в libc?
У Вас есть возможность отправить багрепорт или свой патч, чтобы не «ходить и унижаться»
У меня есть не только возможность отправить багрепорт или свой патч, но и опыт отправки как багрепортов, так и патчей, и оперативность внесения последних оставляет желать лучшего.
По крайней мере так было с Qt 4.6, когда патч был прислан недели за 3 до релиза, но в релиз так и не вошёл (хотя патч был простейший, в одну строку — проверка на ненулевой указатель).
По крайней мере так было с Qt 4.6, когда патч был прислан недели за 3 до релиза, но в релиз так и не вошёл (хотя патч был простейший, в одну строку — проверка на ненулевой указатель).
3 недели — это уже практически финальное тестирование. Поэтому я думаю после выхода RC1 а то и раньше новые фиксы не вносятся, только тестируется и правиться текущая сборка, чтоб быть уверенным, что ничего не поломалось.
Если после выхода RC1 не фиксятся критические баги (а баг был критический: краш при обращении по нулевому указателю) — то какой смысл называть это «RC1», а не выпускать сразу «релиз»?
>… новые фиксы не вносятся, только тестируется и правиться текущая сборка
«Тестируется и правится» и «фиксы не вносятся» — как такое возможно? «Правится» означает «вносятся фиксы», т.к. «фиксы» по-русски называются «правки». Или я чего-то не понимаю в этой жизни.
>… чтоб быть уверенным, что ничего не поломалось.
Вот я и сообщил им, что кое-что таки поломалось (в 4.5 этой проблемы не было), показал где именно поломалось и даже показал как это починить. Результат озвучен выше.
>… новые фиксы не вносятся, только тестируется и правиться текущая сборка
«Тестируется и правится» и «фиксы не вносятся» — как такое возможно? «Правится» означает «вносятся фиксы», т.к. «фиксы» по-русски называются «правки». Или я чего-то не понимаю в этой жизни.
>… чтоб быть уверенным, что ничего не поломалось.
Вот я и сообщил им, что кое-что таки поломалось (в 4.5 этой проблемы не было), показал где именно поломалось и даже показал как это починить. Результат озвучен выше.
Вы упорно не хотите понимать?
Есть продукт А, в который вносится ряд изменений, в том числе из баг трэкера.
До определенного момента вносятся в него изменения (сейчас одобряются запросы на мерж в gitorious)
В какой-то момент запросы на мерж больше не приниматся, продукт отдают на тестирование. И там уже тестируют именно влияние изменение на предыдущем этапе. Это похоже не бюрократию, но при вовлечении большого количества людей в проект по другому будет еще тяжелей.
Я понимаю, что выглядит абсурдно. Вроде багфикс, а на этапе тестирования и поиска багов он не был внесен в код. Но видимо этот багфикс не был связан с багами, возникшими в последствии багфиксов и добавления новых фич на предыдущем этапе.
Есть продукт А, в который вносится ряд изменений, в том числе из баг трэкера.
До определенного момента вносятся в него изменения (сейчас одобряются запросы на мерж в gitorious)
В какой-то момент запросы на мерж больше не приниматся, продукт отдают на тестирование. И там уже тестируют именно влияние изменение на предыдущем этапе. Это похоже не бюрократию, но при вовлечении большого количества людей в проект по другому будет еще тяжелей.
Я понимаю, что выглядит абсурдно. Вроде багфикс, а на этапе тестирования и поиска багов он не был внесен в код. Но видимо этот багфикс не был связан с багами, возникшими в последствии багфиксов и добавления новых фич на предыдущем этапе.
Да, я упорно не хочу понимать, зачем выпускать публичный RC и отдавать его во внешнее тестирование, если баги (включая критические), обнаруженные в процессе этого самого тестирования, не правятся перед релизом. И уж тем более если это очевидная регрессия по сравнению с предыдущей версией продукта.
Видимо, я слишком привык к «более другой» культуре разработки, тестирования и внедрения продуктов.
Видимо, я слишком привык к «более другой» культуре разработки, тестирования и внедрения продуктов.
Ну, такая проблема действительно есть. Тролли очень медленно принимают мерж-реквесты с Gitorious, некоторые заявки по году и больше висят. Ну, и сокращение цикла между бета-версией и релизом у них тоже, видимо, произошло не от хорошей жизни. Итого — на баги Nokia Qt Software зачастую откровенно кладёт болт.
Хотя у моего коллеги было обиднее. Сделал патч для Creator, патч довольно быстро приняли и перенесли в master. Смысл патча: creator переключал объявление/определение функции без учёта её полной сигнатуры, что при множественной перегрузке функций работало мягко говоря странно. А спустя месяц мы с ним в очередной раз слили master о офигели — переключение вообще сломали нафиг. Оно на последних снэпшотах вообще работает через раз и зачастую переключает вообще не на те функции. Такие дела.
Хотя у моего коллеги было обиднее. Сделал патч для Creator, патч довольно быстро приняли и перенесли в master. Смысл патча: creator переключал объявление/определение функции без учёта её полной сигнатуры, что при множественной перегрузке функций работало мягко говоря странно. А спустя месяц мы с ним в очередной раз слили master о офигели — переключение вообще сломали нафиг. Оно на последних снэпшотах вообще работает через раз и зачастую переключает вообще не на те функции. Такие дела.
Постили мы баги для Симбиана, судя по логам, все они были исправлены, но я пока не пробовал обновлять Qt
Стоит также заметить, что обновили VS Add-in, в котором наконец добавили поддержку Visual Studio 2010.
Странно, улучшений в подсистеме QtSql не перечислено… Хотя в драйвере ODBC был один критический баг (http://bugreports.qt.nokia.com/browse/QTBUG-11750).
Но все равно, Qt — вещь!
Но все равно, Qt — вещь!
Скажите, может я что-то не понял? Начал качать Qt, версию для Win32, LGPL, файл называется ...2010.05.exe Не обновили дистрибутив или я туплю?
Sign up to leave a comment.
Qt 4.7.0 Released