Баганутость российского ПО (30.09.2022).

" title="Написать письмо">Написать письмо

Донаты на карту ВТБ:
2200 4002 2461 6363

Статьи по разделам

Статьи по дате (многие всегда актуальны)

Испытано на себе

Творчество

Прочие разделы

Вечно актуальные статьи

Статистика

Пользователи : 1
Статьи : 2154
Просмотры материалов : 8034958

Баганутость российского ПО (30.09.2022).

2022 - Сентябрь

30.09.2022 17:13

Save & Share

← Замена вентилятора видеокарты (22.09.2022).		Wagon Wheels (30.09.2022). →

~~ИА Панорама~~ КБ Панорама, продукт ГИС Конструктор/Оператор, отвечающий за отображение карт и рисование на их поверхности. Выявленные баги российской Astra Linux (а еще будет научная работа по поводу другой версии этой ОС) - это ничто, в сравнении с этим ПО. Возможно, унитаз российского производства поспорить сможет.

Требовалась тривиальная, на первый взгляд, задача: открыть карту, выделить область, сохранить область в файл PNG. В Windows эта задача решилась бы (наверное) простой функцией "что-то-там-Save-BMP" из крайне неинформативного руководства системного программиста ГИС. Но в линуксе ни одна простая задача не дается просто. Посмотрев похожий код в очень сложном проекте, выяснилось: код по ГИС настолько был переплетен с проектом, что вытащить его оттуда оказалось невозможным. Значит, тот, кто писал код, не обеспечил этому проекту должную модульность - и, вероятно, это было по вине больших трудностей написания: огромной трудоемкости и сил.

Напрягся от такой мысли. Было решено писать с нуля, заимствуя из проекта примерную парадигму работы с ГИС - но не функции, там встречающиеся. Как выяснилось, не зря (API-функции ГИС - корявые):
- пусть нужно вписать путь карты как входной параметр функции открытия. Но таких функций 3 - и все они работают одинаково, а требования к ним разные. В одной функции может быть все нормально, другая отказывается путь принимать, требуя свой тип данный WCHAR. При этом парадокс в том, что WCHAR ГИСа - это не wchar_t Linux или WCHAR=wchar_t Windows API. Самым легким вариантом оказалось использование функции, которая требовала char*, - и найти из множества способов конвертации данных рабочий: const char *cMap_Path = strData_SQL.strBZ[0].qsMap_Path.toUtf8().data(). В этот момент понимаешь: если такие "особенности" идут в самой же первой строчке кода - дальше будет засада;
- и эта засада не заставила себя ждать. Функции QDMapView (без нее русские символы не отображаются корректно) и mapOpenMap - уничтожают содержимое всех переменных char* в своей области видимости (даже если они const и не являются входными параметрами функции). Открыл карту с помощью mapOpenMap, указав путь const char*, - этот путь и все char* в округе станут пустыми или односимвольными (когда как);
- открытия карты - недостаточно для открытия карты. Карта без сетки и надписей - жалкое зрелище. И их подгружать бы автоматически или как параметр открытия - но нет: нужно подгрузить вручную еще 1 определенный файл. И зрелище не только жалкое, но и слепое: т.к. сохранение рисунка еще не реализовано, и визуального интерфейса нет, - фактического результата работы функций не видно - и остается только наблюдать возвращаемые ими значения, интерпретированные одинаково: "если вернула 0 - функция выполнилась ошибочно - расшифровать ошибку невозможно". И это полная дичь, потому что в нормальных функциях всегда возвращается код ошибки (0 - если норма). А некоторые функции - вообще void: отработают неправильно - и не узнаешь.

К неинформативности руководства системного программиста (например, про подключаемые LIBS - ни слова), в свою очередь, добавилась проблема: API-файлы имеют русскоязычные комментарии к коду - но они убиты сохранением этих файлов в неизвестной кодировке. Ни в Linux, ни в Windows (даже с использованием ПО Штирлиц) - эту кодировку H-файлов расшифровать оказалось невозможно.

Понимая, что вслепую работать практически нереально, - было решено идти в ТП. Был проведен анализ: предприятие закупило дохрена лицензий за последние 6 лет. И когда был отправлен запрос в ТП по указанной на сайте электронной почте для обратной связи - пришел исчерпывающий ответ: вали на форум. На форуме не работала корректно регистрация (невозможно войти по правильно введенным логину и паролю). Админы форума копались в моей учетке после запроса - и вот, наконец-то, смог открыть свою тему. Выяснилось, что форум мертвый: "пользователь" и админ, отвечающие на сообщения, - единственные ответчики и сотрудники ГИС. И один из них дал исчерпывающий ответ: вали в мануалы. Я им пишу в абсолютно корректной форме: "Вы что, уху ели, отказывать владельцу лицензий в техподдержке?". В результате, был дан исчерпывающий ответ: да вот тебе пример работы с картами.

А дальше начинается самое интересное:
- я написал им исчерпывающую информацию: название и версию ОС, среды программирования, установленного продукта ГИС, конкретную задачу (далее им на почту даже исходники были высланы на анализ). Им этого мало: начинают доеживаться, каким способом я пишу свое ПО. Сыпят скопированными функциями из руководства программиста, не объясняющего их сути. Не отвечают по почте вообще ни на что, в т.ч. на запрос предоставить расшифровку файлов в неверной кодировке;
- пример, выданный ими, имел фатальные ошибки, выявить которые помогли только навыки тестировщика. С учетом того, что пример они давали из мануалов новых версий, а у меня более старая версия, - все ошибки идут сквозь версии, и никто не думает их исправлять. Хотя стоит признать: без этого примера ничего бы не вышло;
- в конце всей этой канители выяснится: ТП отредактировала и собственные сообщения в теме, и мои. Цензура потрясающая - и ни один из приходящих на сайт пользователей не узнает ни абсурдности ситуации, ни багов их продукта (потому что и мое описание багов они тоже потерли).

А баги примера были волнующими:
- логично было бы выбрать кратчайший путь разработчикам ГИС - и написать в API ГИС функцию, сжирающую 2 точки координат, строящую по ней прямоугольник и готовящую этот прямоугольник для сохранения в файл. И функцию сделать перегруженную: чтобы и текстовые координаты принимала, и радианные, и тип системы координат. Но нет: текстовые координаты должны быть преобразованы именно в радианы, радианы - в метры на местности, метры на местности - в пиксели. Еще это все зависит от масштаба карты, выполняется в строгой последовательности отдельных функций или вообще своими руками;
- при работе с большими изображениями (которые, "внезапно", нужны для печати карт на A0), происходило скрытое переполнение входного параметра их функции AllocateTheMemory. В результате, в изображение сохранялась дичь, иногда даже повернутая на произвольный угол и кусками пустая (а ты, тем временем, еще на себя бочку катишь, думая, что сам написал ошибочный код);
- для правильного двойного вызова функции mapPlaneToPicture (2 же точки) требуются жесткие условия в метрах на местности: X1<X2, Y1>Y2. Если не распарсить входные координаты по этим абсурдным правилам - в рисунок будет сохраняться совершенно другой участок карты. Это было выведено имперически: естественно, никаких комментариев по координатам на эту тему не было - попробуй, догадайся;
- совокупность масштаба карты и диапазона координат - приводит к большим ширине и высоте сохраняемого изображения. В функции подготовки изображения для сохранения в файл mapPaintToXImage это не анализируется - последующий объект QImage, в итоге, скрыто крашится. Или второй вариант: даже malloc не хватит для корректного выделения нескольких гигабайт памяти. То есть, для корректного сохранения рисунка нужно не просто контролировать, чтобы изображение не выходило за (2²⁹-1) 4-байтных пикселей по объему, - но и изменять масштаб (порождая при этом соответствующие ограничения показа участка карты).

А ведь это всё - только описание действия сохранения участка карты в файл. Это не более 15% итоговой работы.

Назрел простой вопрос, как по Linux, так и по ГИС: зачем такое забагованное, алогичное и труднообслуживаемое говно внедряется в оборонной промышленности? Ведь это диверсия не только по отношению к программистам (сколько их поувольнялось при переходе с Windows на Linux - подумать страшно). Но и к обороноспособности страны в целом. А ответ известен: Сноуден в свое время про закладки в ОС, ПО и железо - сказок СБ-шникам понарассказывал. И наверху запретили Windows, полностью, - а альтернативы-то нет. И вместо изучения Windows и выпуска отдельных исправлений для устранения закладок в ОС (если они вообще существуют) - была написана "своя" Linux. "Своя" - потому что на импортном ядре Debian (его разработчик - Software in the Public Interest, Нью-Йорк, США).

(добавлено 02.10.2022) Потрясающий ответ от ТП. Они считают баг - фичей (даже заскринил свой ответ на него, на память: а то потрут еще). Потому что между 3-мя первыми ответами по теме (если будете искать) было мое сообщение - и теперь оно тоже стерто. Что примерный алгоритм не может быть ответом ТП на вопрос (как и сыпание функциями из справочника простой копипастой). Собственно, их примерный алгоритм с кучей ошибок - и является примером такого ответа, повлекшего кучу потраченного времени и гемора. У меня уже готова функция, сохраняющая прямоугольник с координатами корректно, - но она в корне отличается от предоставленного примера. И самоконтроль в этой функции пришлось делать встроенный, обрабатывая не только глюки API ГИС, но и технические ограничения среды Qt.

И еще баг обнаружился. В зависимости от масштаба, надписи на слое информации по инфраструктуре карты - плывут. При сохранении одного и того же участка карты: в масштабе 1:5000 надпись написана четко по центру лесной области, а при 1:50000 - улетает за пределы этой области влево и, как следствие, обрезается в сохраняемом рисунке.

(добавлено 03.10.2022) Потерли, кто бы сомневался.

(добавлено 04.10.2022) И еще один баг в примере от ТП. Функции mapCloseMapAccess и mapCloseData должны быть поменяны местами, т.к. в глубинах руководства системного программиста нашелся комментарий «освободить ресурсы ядра перед закрытием приложения». А закрытие карты, оказывается, в том же руководстве, - и описывается как закрытие приложения.

Также пришла информация от сотрудников другого подразделения по месту работы. Там все то же самое: плюются от багов ГИС, их сообщения о багах трутся с форума. И, самое главное, ТП использует чужой труд для нахождения багов в своем продукте. То есть, меня поимели, т.к. я выступил бесплатным тестировщиком их продукта в контексте примера ТП.

(добавлено 05.10.2022) Чтобы было понятно более простым языком о баганутости этого софта. Вот так выглядит точная карта Пакистана в масштабе >1:200.000, по мнению программы ГИС. Внутри API ГИС: скорее всего, повреждается выделенная память при формировании изображения.

(добавлено 18.02.2023) Гуглим на хабре "Программное обеспечение на российской ОС" пользователя MAXPribalt. Ее можно на цитаты разбивать: "ИТ-архитекторы поддакивали, а технический персонал никто слушать не стал", "бег по граблям с энтузиазмом". Статья - 2022 года, что намекает, что за 8-10 лет ничерта не изменилось.

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

(добавлено 30.08.2023) При подготовке миграции на другую версию Linux - вышло 2 перла:

- от разработчика Astra: даже нормально запаковать репозиторий Develop не могут. Это не tar, а tar.gz - и после распаковки gzip еще нужно распаковывать как tar;

- от разработчика ИА Панорама: руководство программиста от 2023 года имеет дату на заголовочной странице "2014". Количество листов больше, чем в имеющемся на руках руководстве от настоящего 2014 года. 9 лет не исправляли дату - и никто не обратил на это внимания.

Ну как можно работать с такими рукожопами, а...

(добавлено 25.03.2025) И даже спустя годы: баги ГИСа продолжают оказывать пердакоподжигающее действие. Возможно, стоит просто комментарии из исходников сюда вставить: что этот ГИС вытворяет. И это неполный список: баги скопированы только из 1 файла проекта.

Баги ГИС:
- отвратительная ТП. Из почты посылают в форум, из форума - в мануал (и ФЗ, и юрлиц). Или дадут пример - но он будет с тонной багов.
Признавать баги продукта отказываются, удаляют мои сообщения с форума об этом, корректируют свои написанные ранее сообщения. При попытке общения по почте после посыла на форум - полный игнор;

- QDMapView и mapOpenMap - уничтожают содержимое всех char* внутри функции, даже если они const. Пришлось работать с QString с многоуровневым перетипированием;

- mapOpenAnyData требует const WCHAR* - его получение из QString возможно только перетипированием toWCharArray в wchar_t[100] и поэлементным копированием в WCHAR[100].
Разницы между mapOpenAnyData, mapOpenMap, mapOpenMapUn, mapOpenMapPro не замечено - используется более удобная mapOpenMap;

- функции по работе с координатами не имеют самоконтроля - и при этом начинают глючить, если координаты перепутаны (мало того, требуется алогичный их порядок). Отрисовываются совсем другие координаты или вообще пустой рисунок.
    Независимо от двух получаемых координат, требуется выполнение условий X1>X2, Y1<Y2 - то есть, координаты приходится перетасовывать. Мало того, у них X - вертикальная ось.
    И это при условии, что для отрисовки прямоугольника на карте по 2 точкам - расположение 2 точек не имеет значения;

- при изменении масштаба, рисунок, вероятно, сохраняется со смещением по координатам в несколько пикселей. Анализатор этого не писался, ввиду отсутствия времени и неясности его алгоритма;

- иностранные надписи на карте при изменении масштаба смещаются относительно карты. На примере названия "...mad Khosa": 50000 - Khosa в центре зеленой области рисунка, 5000 - смещается и остается обрезанная "osa" в левой части рисунка;

- переполнение int как входного параметра AllocateTheMemory. С уменьшением числа масштаба в mapSetViewScale и увеличением диапазона сохраняемых координат, размер изображения растет - проблема возникает уже на квадратном изображении в несколько тысяч пикселей.
    Усугубил положение пример от ТП ГИС, где входной параметр сначала умножался на глубину цвета 32 и потом делился на 8. Пришлось использовать стандартные malloc и free - и обязательно double как входной параметр с домножением интовых переменных на .0;

- после разноса функций API ГИС по самописным функциям, было замечено расхождение <0.1% в получаемых числах метров на местности и пикселей, относительно неразнесенного исходного кода. Баг ушел сам или при незапомненном исправлении.
    Перетипирование никаких переменных при этом не проводилось, float вместо double не используется;

- mapSetViewType имеет 12 видов отображения элементов карты. Однако часть сохраненных изображений с разными видами - оказались полностью идентичными (проверено с помощью Total Commander: дубликаты);

- часто mapPaintToXImage добавляет артефакты в сохраняемое изображение (малые группы пикселей инородного цвета);

- для работы с картами требуется вручную добавить в проекте "LIBS += -lqdmapacces -lmapcomponents -lqdmapqtfrm". Но в обоих руководствах программиста 2005 и 2014 года об этом - ни слова. Позже ТП добавила эту информацию - но это было уже неважно: взял из других исходников;

- невозможно сохранять большие участки точной карты: в рисунок сохраняется белиберда. Те же координаты при том же алгоритме - корректно сохраняются при использовании обзорной карты.
    Связано с ограничением на масштаб ~300.000 (но лучше 200.000):
      - при несильном превышении: начинает появляться темнозеленый фон снизу, карта становится рваной (пустота ГИС: карта не прямоугольная);
      - если еще увеличить масштаб: начинает появляться желтые пестрые участки сверху;
      - если еще увеличить: создается впечатление, что карта пытается сохранить в рисунок весь мир. При этом он содержит в себе прямоугольные участки либо как обрамление черными линиями, либо как цветастый прямоугольник.
        Появляется серая зона снизу (ниже зеленой): холст рисунка больше сохраняемого в него изображения.
    Навигация по карте в этом случае осложняется еще и тем, что карта меняет оттенки суши, входя в допуск масштаба (на примере Пакистана - много гор, местность становится все краснее).
    Для визуальной оценки, что происходит с картой Пакистана с изменением масштаба, см. примеры в папке "Точная карта Пакистана при увеличении масштаба", созданной при разработке данного модуля;

- все файлы .H имеют испорченную кодировку - не берут даже программы-перекодировщики (вроде Штирлиц). ТП отказывается давать файлы в нормальной кодировке. В итоге, как ни странно, оказалась кодировка KOI8-R.
    Веб-справочник /usr/share/qt4/doc/gisdesigner11/Helpapi неполный - т.к. содержит далеко не все функции + иногда ссылается на эти-самые .H-файлы.
    Руководство системного программиста 2005 года, казалось бы, не является просто справочником и содержит примеры, - но не содержит главного: точного описания взаимосвязей между функциями.
      Примеры:
        - mapRegisterDrawObject и mapRegisterObject приводят к повреждению отображаемого объекта (часть пропадает);
        - описание функций AllocateTheMemory, mapOpenMap, mapAppendPointGeo - полностью отсутствуют. В руководстве 2005 года mapOpenMap упоминается вскользь, в 2014 - не упоминается;
        - mapCloseMapAccess - имеет обтекаемую формулировку вида "вызвать, если было обращение к ГИС Серверу". При этом как проверить, были ли обращения ранее, - непонятно.
            Единственная зацепка - mapIsMapFromServer. Поэтому функцию mapCloseMapAccess приходится вызывать без какого-либо анализа, на всякий случай;
        - эмпирически выяснилось, что для открытия карты необязательно открывать файл .MAP - можно подсунуть .MTW. Такая ситуация в справочнике не описана;
        - mapSetViewScale заявлена как функция изменения масштаба карты (ее описание в руководстве состоит всего из 1 строки). При этом не предупреждается, что при большом масштабе точная карта начинает глючить;
        - mapSetObjectPress и mapSetObjectScale не работают должным образом (масштабирование не отключается, или функция отваливается при перемещении в другое место);
    Возможно, поэтому примеры от ТП содержали критические баги: сами составители руководства не представляют поведения функций не в абстрактных примерах, а при боевом применении в прикладных задачах.

- не все объекты для отрисовки способны отрисовываться на карте. IMGCIRCLE и IMGLINE - норма, IMGDOT, IMGSQUARE, IMGHATCHSQUARE - не видны.

(добавлено 06.04.2025) Стоит добавить ещё одну вещь, если не была указана за эти годы. Когда делал миграцию продукта на более новую астру - именно карты ГИС не дали завершить эту задачу и победить в более глобальной битве. Так и не смог заставить карты работать внутри продукта - а ещё затрахался с их физическими ключами, без которых ГИС отказывается работать. В 2014 году такого дерьма не было - вот, взяли, ключи какие-то придумали.

Теги:

Обновлено ( 06.04.2025 19:18 )

Статьи по разделам

Статьи по дате (многие всегда актуальны)

Испытано на себе

Творчество

Прочие разделы

Вечно актуальные статьи

Статистика

Последние теги

Самые популярные теги

Самые читаемые теги

Случайные теги

Последние новости