В 2022 году, когда ботинки Ecco не стоили 23к и были нормального качества, началось соревнование у заказчика и начальников под названием "кто сильнее нагрузит разработчиков". Закончилось это плачевно для разработчика (исполнители, как рабы, имеют максимальные потери от рабочих нагрузок).

Теперь, по причинам выше не являясь больше программистом (а, скорее, инженером-тестировщиком), - программистское прошлое всё равно настигает: это как в ремиссию при отказе от курения уйти - и потом снова сорваться. Пришли новые данные от заказчика - изменяющие исходные данные. После изменения их программистом, нужно протестировать все свои прошлые наработки в составе конечного продукта, исправить ошибки. И понеслась.

Модуль по работе с участками мировой карты потребляет гигантское количество ресурсов: до 40ГБ RAM. При работе с таким объёмом данных и количеством объектов - ошибки при работе с памятью неминуемы; однако тогда, за счёт постоянных сверхурочных работ, - удалось довести продукт до идеального состояния. Однако был узкий момент: глючное ПО ГИС от Панорамы, причём настолько - хоть вешайся. И оно проявило себя повторно при глубоком тестировании в этот раз.

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

Поэтому, когда модуль несколько раз в день мог вылететь без причины, - в руководстве оператора было указано прямо так: "Для устранения ошибки: подождите 5 минут и запустите модуль заново". Понятное дело, что ошибка никуда не девалась, просто временно пряталась и долго могла не появляться.

Ошибка крылась в строке: "hSite_RSC = mapCreateAndAppendSite(hMap_500, qsSite_RSC_Path.toUtf8().data(), qsRSC_Path.toUtf8().data(), &csJunk);". При этом, например, при 50-м срабатывании, вылетала страшная ошибка: "*** glibc detected *** /path/formular: double free or corruption (!prev): 0x0000000001ea0d70 ***". Настолько страшная - что модуль падал замертво ("Приложение остановлено, так как оно получило сигнал от операционной системы SIGABRT"). Далее в дебаге написана куча технических данных, затрагивающих даже libQtCore и шрифты, - полезного там мало.

Причина ошибки: попытка сделать free() для уже освобождённой памяти. То есть, только что создал переменные, использовал их при создании нового объекта - а ГИС иногда хочет им free() сделать (а может, и 2 раза подряд - отсюда и баг).

Решение оказалось найденным на одном-единственном форуме, каком-то жалком хабре, старая тема от 2009 года. Все прочие темы, вопросы и форумы - заканчивались молчанием ТС: он просто забивал на проблему, потому что никто в теме ему не мог помочь. Решение выражалось в запуске с таким параметром перед исполняемым файлом, при котором анализатор glibc (отслеживающий такие ошибки и вынуждающий приложение закрываться) - шёл в пешее эротическое. При этом, несмотря на то, что ОС посылает сигнал принудительного закрытия приложения, - данное решение никак не влияет на ОС (в т.ч. не содержится в глобальных переменных) и выполняется даже в жёстких ограничениях учётной записи. То есть, решение применяется исключительно к запускаемому модулю.

MALLOC_CHECK_=0 пробел путь_к_бинарнику.

Изначально убедившись, что в терминале данная строка успешно отработала на калькуляторе, - было создано искусственное двойное очищение выделенной памяти уже в новом проекте Qt. И вызывая собранный бинарник именно с данным параметром слева - вылет уже не наблюдался, можно было дальше смотреть на форму и жмякать на кнопку - насилуя память всё больше и больше (при этом, после двойного очищения, код ниже отрабатывал исправно). Ну а дальше - внедрение решения в родительский модуль, запускающий модуль работы с картами ГИС.