Pull to refresh

Comments 53

Отлично. И теперь дождаться бы для Maemo.
мне что-то подсказывает, что нового обновления для Маемо не будет :-) Будем ждать MeeGo с 4.7 на борту.
А что мешает пакет от MeeGo пересобрать для Maemo?
да ничего не мешает вообще собрать Qt для Маемо, но приложение с такой зависимостью в Ovi store уже не положишь.
Как мне кажется, если и будет, то раньше чем MeeGo. Будет время под эту Мигу на N900 отточить приложение с использованием 4.7. Ну а если не будет, то жаль, но да и ладно…
Да само MeeGo пишут на 4.7, так как там широко испольузется Qt Quick, так что они отлаживают в процессе разработки.
Для N900 будет MeeGo, так что действительно «ну да и ладно».
Qt радует все больше и больше. Правильным путем идут товарищи.

PS Ссылка на changelog уже работает.
Ага, спасибо, убрал дисклеймер :)
Интересно, поправили ли вопиющие баги (в частности, когда Qt падает при отрисовке компонента QScintilla) или опять придётся самому патчить, пересобирать и ждать, когда же они сподобятся раскачаться =\
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.
это ни о чем не говорит. Если конструктор QsciScintilla например вызывает метод у неинициализированног класса qDrawArrow, то естественно выполенние упадет именно в методе класса qDrawArrow, так как он полезет к данным экземпляра класса (к this например) и нарвется на мусор.
Так что я вообще не уверен, что бага в Qt судя по этому вот дампу.
Ну, начнём с того, что qDrawArrow — это не класс, а функция (отдельная, не метод класса), поэтому речь о «недоинициализации» не идёт. Далее отметим, что в Qt 4.6 (и младше) тот же самый код работал без каких-либо проблем, а краш появился при апгрейде Qt с 4.6 до 4.7. Будем предполагать дальше?
Код работал без проблем, не значит, что он правильно работал
я написал слово «например», но как еще один вариан, это может быть, НАПРИМЕР, вызван метод у передаваемого QPainter или еще чего.
Чтоб быть точно увереным нужно не дампы смотреть, а запустить с дебажными кутишными библиотеками и отладочную QScintilla и посмотреть кто есть кто. А гадать — это не инженерный подход.
НАПРИМЕР может быть всё, что угодно. Хоть повреждение памяти. В том числе и физическое.
Гадать, действительно — не инженерный подход. Вот только кто из нас больше «гадает» в этом треде — Вы или я?
Гадаете вы, у вас нет доказательств, что ошибка в Qt, только стек с именами функций, в которые могли быть переданы невалидные параметры. Чтобы не гадать, нужно взять отладочные символы и посмотреть что там с QPainter* в первую очередь.
Ну конечно, я. Это же я с дебаггером обнаружил, что «если конструктор QsciScintilla например вызывает метод у неинициализированног класса qDrawArrow, то естественно выполенние упадет именно в методе класса qDrawArrow, так как он полезет к данным экземпляра класса (к this например) и нарвется на мусор».

И фиксы к Qt 4.6 я тоже «гадательные» присылал. Которые потом вошли в 4.6.1, хотя были присланы за 3 недели до релиза 4.6.0. Видимо, ребята из Nokia тоже увлекаются эзотерикой и «гаданиями», только не так серьёзно, как я.
Ой, простите, забыл откомментировать:

>… только стек с именами функций, в которые могли быть переданы невалидные параметры

А валидация параметров — для лохов. Более того: настоящие мачо не просто не делают валидацию (сами проверяйте, чего передаёте), а делают так: сначала проверяют все параметры, чтобы у всех всё работало, а потом, в одном из релизов (не в каком-то там 0.3 или 0.4, а круче: в 4.6 или 4.7) р-р-раз — и убирают проверку. Чтоб сторонние девелоперы не расслаблялись и не теряли форму. Ну и мейнтейнеры дистрибутивов заодно, которые потом патчат сорцы при сборке, иначе ломается куева туча софта в дистрибутиве.

Вы ведь не подумайте чего плохого: я работаю с Qt с ранних 3-их версий и считаю, что это прекрасная библиотека в всех смыслах этого слова (лучшая в своём классе и даже в некоторых «смежных классах»). Но то, что стало с качеством кода и с самим подходом к разработке после того, как Нокия купила Троллтек, мне решительно не нравится.
qDrawArrow — недокументированная функция, во всяком случае в Assistant про неё ничего нету и в публичных хедерах она не упоминается. Она вполне может не валидировать входящие параметры, а полагаться на то, что они будут провалидированы тем, кто её вызывает. Её вообще могут переименовать в следующем релизе. Так что не надо тут про р-р-раз и убирают проверку, могли и функцию убрать, нечего пользоваться приватным недокументированным АПИ.
>… нечего пользоваться приватным недокументированным АПИ.

Конечно, нечего. Вот только никто и не пользуется: в сорцах QScintilla вызов данной функции (как и любой другой qDraw*) не встречается ни разу. А вот кто её вызывает и почему не валидирует входящие параметры (раз уж функция на это полагается) — хороший вопрос, правда? ;)
Хороший. Ну так надо взять отладчик, символы и сорцы и выяснить, кто виноват. В любом случае, то, чем мы с вами сейчас занимаемся — гадание на кофейной гуще. В условиях наличия исходников это даже как-то странно выглядит :)
Чисто ради проформы: я смотрел в исходники ещё до того, как появился этот тред ;)
Судя по трейсу qDrawArrow метод вызывается из конструктора QsciScintilla => либо у вас исходники от левой версии либы, либо левый трейс, либо косяки с логикой
Версия с левыми исходниками и левым трейсом понятна. Поясните, откуда следуют мои косяки с логикой. Есть ещё версия с настройками дебаггера, но она не такая интересная :)
Вот как можно пояснить откуда с логикой косяки, если мы кода не видели? Услуги телепатов нынче дорого стоят.
>Вот как можно пояснить откуда с логикой косяки, если мы кода не видели?

Эх, если бы все рассуждали как Вы — не было бы этой длинной ветки… :)
а как еще возможны ваши выводы, если предположить, что и трейс верный, и исходники те?)
как бы то ни было — ничего личного :)
Возможно функция какая-то проинлайнилась.
В общем я покопался по сорцам, qDrawArrow вызывает qDraw[Win|Motif]Arrow, которая таки не валидирует QPainter* p. Но она вообще помечена как QT3_SUPPORT и давным давно задепрекейчена. Ну и вообще, кому может прийти в голову рисовать непроинициализированным пеинтером?
>Ну и вообще, кому может прийти в голову рисовать непроинициализированным пеинтером?

Вот и меня этот вопрос очень интересует. Особенно в свете того, что это происходит внутри самой Qt (см. комментарий выше).
А если вы напишете где-то у себя в коде memcpy(0, 0, 10000); и увидите в 0 фрейме memcpy, вы начнете подозревать, что ошибка в libc?
Разумеется, а как же иначе?
У Вас есть возможность отправить багрепорт или свой патч, чтобы не «ходить и унижаться»
У меня есть не только возможность отправить багрепорт или свой патч, но и опыт отправки как багрепортов, так и патчей, и оперативность внесения последних оставляет желать лучшего.
По крайней мере так было с Qt 4.6, когда патч был прислан недели за 3 до релиза, но в релиз так и не вошёл (хотя патч был простейший, в одну строку — проверка на ненулевой указатель).
3 недели — это уже практически финальное тестирование. Поэтому я думаю после выхода RC1 а то и раньше новые фиксы не вносятся, только тестируется и правиться текущая сборка, чтоб быть уверенным, что ничего не поломалось.
Если после выхода RC1 не фиксятся критические баги (а баг был критический: краш при обращении по нулевому указателю) — то какой смысл называть это «RC1», а не выпускать сразу «релиз»?

>… новые фиксы не вносятся, только тестируется и правиться текущая сборка

«Тестируется и правится» и «фиксы не вносятся» — как такое возможно? «Правится» означает «вносятся фиксы», т.к. «фиксы» по-русски называются «правки». Или я чего-то не понимаю в этой жизни.

>… чтоб быть уверенным, что ничего не поломалось.

Вот я и сообщил им, что кое-что таки поломалось (в 4.5 этой проблемы не было), показал где именно поломалось и даже показал как это починить. Результат озвучен выше.
Вы упорно не хотите понимать?
Есть продукт А, в который вносится ряд изменений, в том числе из баг трэкера.
До определенного момента вносятся в него изменения (сейчас одобряются запросы на мерж в gitorious)
В какой-то момент запросы на мерж больше не приниматся, продукт отдают на тестирование. И там уже тестируют именно влияние изменение на предыдущем этапе. Это похоже не бюрократию, но при вовлечении большого количества людей в проект по другому будет еще тяжелей.

Я понимаю, что выглядит абсурдно. Вроде багфикс, а на этапе тестирования и поиска багов он не был внесен в код. Но видимо этот багфикс не был связан с багами, возникшими в последствии багфиксов и добавления новых фич на предыдущем этапе.

Да, я упорно не хочу понимать, зачем выпускать публичный RC и отдавать его во внешнее тестирование, если баги (включая критические), обнаруженные в процессе этого самого тестирования, не правятся перед релизом. И уж тем более если это очевидная регрессия по сравнению с предыдущей версией продукта.
Видимо, я слишком привык к «более другой» культуре разработки, тестирования и внедрения продуктов.
Ну, такая проблема действительно есть. Тролли очень медленно принимают мерж-реквесты с Gitorious, некоторые заявки по году и больше висят. Ну, и сокращение цикла между бета-версией и релизом у них тоже, видимо, произошло не от хорошей жизни. Итого — на баги Nokia Qt Software зачастую откровенно кладёт болт.

Хотя у моего коллеги было обиднее. Сделал патч для Creator, патч довольно быстро приняли и перенесли в master. Смысл патча: creator переключал объявление/определение функции без учёта её полной сигнатуры, что при множественной перегрузке функций работало мягко говоря странно. А спустя месяц мы с ним в очередной раз слили master о офигели — переключение вообще сломали нафиг. Оно на последних снэпшотах вообще работает через раз и зачастую переключает вообще не на те функции. Такие дела.
Постили мы баги для Симбиана, судя по логам, все они были исправлены, но я пока не пробовал обновлять Qt
а разве уже доступны обновления для Symbian ??? Там же вроде пока они положат в «репозиторий» из и сделают доступными для обновления проходит чуть ли не месяц и в момент выхода трубят во все трубы отдельно, что теперь на симбиан новый Qt.
спасибо, только этого достаточно для разработки, фишка в том, чтоб Nokia Smart Installer for Symbian‎ умел ставить новый Qt и в Ovi store разрешили постить с зависимостями на 4.7.0

А то ведь можно писать на Qt для Symbain более ранний чем ^1, но почему-то выкладывать это в Ovi Store нельзя.
Стоит также заметить, что обновили VS Add-in, в котором наконец добавили поддержку Visual Studio 2010.
Странно, улучшений в подсистеме QtSql не перечислено… Хотя в драйвере ODBC был один критический баг (http://bugreports.qt.nokia.com/browse/QTBUG-11750).

Но все равно, Qt — вещь!
Насколько я представляю, то в changelog'е у троллей пишутся только новые фичи, а не исправления старых
Скажите, может я что-то не понял? Начал качать Qt, версию для Win32, LGPL, файл называется ...2010.05.exe Не обновили дистрибутив или я туплю?
Это версия Qt SDK. Если будете качать только Qt Libraries в имени архива будет 4.7.0.
Так а почему не 2010.09?
Видимо потому что просто нумеруют по порядку.
Sign up to leave a comment.

Articles