https://marc.info/?l=openbsd-tech&m=169519004327392&w=2

Короткий текст про hardened malloc из openbsd, и как он помогает отлавливать ошибки:

"I'm happy to say two of the more complex ones are (being) fixed: one turned out to be a reference counting bug in firefox. See http://undeadly.org/cgi?action=article;sid=20230912094727

The other, a write after free that crashed the X server when running picard was diagnosed by me. This one was a bit nasty, as it required instrumenting malloc to print some extra info to find the root cause.

The bug is that the call in https://github.com/openbsd/xenocara/blob/master/xserver/Xext/xvdisp.c#L1002 overwrites the first 4 bytes of the chunk next to the one allocated on line 995"

И, попутно, текст про внутренности SCUDO (тоже hardened malloc, используется в Android) - https://trenchant.io/scudo-hardened-allocator-unofficial-internals-documentation/

В очередной раз дебажил проблему в #mesa.

Это уже какое-то дежавю - каждый новый релиз mesa приносит мне новый веселый черный экран.

Самое забавное - что я не могу написать ни одного нового слова по этому поводу, потому что про все эти проблемы в mesa я уже писал, просто они стреляют снова и снова:

* https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_physical_device.c?ref_type=heads#L1839-1842 - ошибка случается вот тут. И тут же происходит полная херня, потому что мы меняем текстовое описание ошибки на целое число, значение которого позже теряется в потрохах всего этого лапшеобразного кода. То есть, вместо простого grep мне пришлось пару часов трассировать этот код в gdb.

* https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_physical_device.c?ref_type=heads#L121-122 - а вот тут суть ошибки. Про него я тоже рассказывал. Эти упыри хотят кешировать шейдеры (кстати, отдельная тема - где это вообще нужно, кроме как на перфтесте какого-то сотрудника Valve, которому нужно натянуть на очередное фиолетовое?), а в качестве части ключа хотят использовать некую сущность, которая однозначно бы идентифицировала эту конкретную сборку mesa, чтобы в кеше не было пересечения. А для этого они используют какую-то магию динамического линковщика, чтобы узнать что-то персистентное для какого-то заранее известного адреса в своей программе - https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/disk_cache.h#L111

Ну и, конечно, если этот хак вернул -1, то мы упадем с черным экраном без вразумительного текста ошибки.

Вот нахуй так говнокодить? Почему нельзя попросить вендоров просто записать при сборке какой-то build id?

Я залечил это, подменив реализацию этих функций на более подходящую для статлинковки реализацию - https://github.com/pg83/ix/blob/main/pkgs/lib/mesa/t/ix.sh#L84-L93

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

https://archlinux.org/packages/extra/x86_64/gumbo-parser/

Так, ну раз Arch переехал на Гришину версию (https://gitlab.archlinux.org/archlinux/packaging/packages/gumbo-parser/-/commit/55a259dddedfac62147b6a042fbddf1ba817dee0), то и нам не зазорно, так думаю!

Снова про #mesa

В цитируемом посте я писал, как ловко запилил процедуры "вычитания" одной статической библиотеки из другой, и почему мне пришлось так делать для сборки mesa.

К сожалению, эта процедура оказалась не очень "робастной" (то есть, апдейт на новую версию был сопряжен с трудностями) - иногда в этих .a оказывался символ с одинаковым именем, но с разной семантикой. В обычной жизни это был какой-нибудь неэкспортируемый из .so символ, и оно как-то жило, ну а у меня случались всякие разные артефакты из-за этой процедуры "вычитания".

Поэтому, в итоге, я решил прекратить экономить на спичках, и сделал по рабоче-крестьянски:

* Условный загрузчик плагинов я оставил как есть
* Ко всем символам, которые были в драйвере opengl, я добавил префикс "o_"
* Ко всем символам, которые были в драйвере vulkan, я добавил префикс "v_"

После чего слил драйвера для opengl и для vulkan в одну общую библиотеку. Да, она получилась больше по размеру, потому что некоторые одинаковые символы получили уникальные имена, но зато это стало лучше отражать то, как жти символы используются в .so (они там тоже дублируются). Ну и исчезли ошибки линковки, когда один и тот же символ объявлен в двух библиотеках.

После этого я, с легкостью, без появления новых странностей, обновился на самую последнюю mesa, чего давно не мог сделать.

https://flak.tedunangst.com/post/www-which-wasm-works

Вот, коллега тоже сталкивается с проблемами "а как же запустить простую программу, собранную в WebAssembly".

При этом коллега не собирал ничего сложного, а "всего лишь" собрал JpegXL кодек.

В общем, пользовательский опыт в #wasm, если не брать песочницы браузеров, пока довольно неубедительный.

Будни #bootstrap

Вот есть такой https://github.com/microsoft/DirectXShaderCompiler

Он мне, сам по себе, не нужен (хотя стараниями Valve теперь DirectX есть и под Linux), но он нужен для сборки #AMDVLK (мне все хочется пощупать альтернативную #mesa-е реализацию).

В целом, он собрался без особых проблем, за исключением получения version info из git при сборке. Вообще, получить свою версию из .git чекаута хотят многие проекты, и бОльшая часть из них косячат.

Вот, и этот проект смешно накосячил.

https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py - скрипт, пытающийся получить version.

Обратим внимание на https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py#L39-L42, тут сразу несколько ошибок:

* самая очевидная - нельзя так ловить все ошибки, потому что можно проглотить ошибку в ситуации, когда глотать ее нельзя (например, .git есть, но он как-то испорчен)

* чуть менее очевидная - этот скрипт ведет себя неожиданно, когда команды git нет в PATH. Потому что subprocess в этом случае кидает FileNotFoundError (поубивал бы за это, если честно), а не CalledProcessError.

* парсинг информации от git не обернут вот в такой fail safe try/catch. То есть, ошибку от git игнорируем, а невозможность распарсить кривой результат - не игнорируем.

Ну, то есть, коллеги не смогли правильно закодить то, что они на самом деле хотели - вернуть какое-то дефолтное значение, если получить реальную информацию не получилось.

Поэтому мне пришлось запилить специальный fakegit для этого проекта, который всегда выходит с ошибкой:

https://github.com/pg83/ix/blob/main/pkgs/bin/dxsc/ix.sh#L25

Потому что мой стандартный fakegit не сработал, по причинам, изложенным выше.

Мораль? Мораль, наверное, такая - код по обработки ошибок гикто не тестирует, потому что это сложно, и он способен сам давать наведенные ошибки, когда начинает срабатывать!

https://github.com/epasveer/seer

А вот вам классный GUI над gdb в ленту.

Я, знаете ли, не люблю пользоваться таким в реальной жизни, потому что:

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

* Второй пункт следует из первого. Мне кажется, что это все, суммарно, приводит к более лапшеобразному коду, потому что человек не имеет в голове структуры программы, он дотрассировал до нужного места, впилил проверку на свой частный случай, и дальше живет спокойно. Несколько раз работал с такими кодовыми базами, мне не понравилось.

Но вот, на днях, пришлось дебажить #mesa, недавно рассказывал про это, а она написана так, как будто у ее разработчиков есть очень хороший визуальный отладчик, если вы понимаете, о чем я. В таком случае можно, потому что построить ментальную модель это лапши уже решительно невозможно!

Ну и наткнулся на этот seer:

* Не требует KDE/GNOME, работает на чистом QT6
* Просто собрался и заработал, без завязок на X11, и вот это вот все.

Понятно, что это не интегрированный отладчик - языка он не знает, по клику мышкой переменнные не показывает. Но исходники цепляет исправно, за переменными можно следить через консоль в gdb, и этого мне хватило.

После перехода на clang17, в выходные перешел на libc++17.

В отличие от прошлого раза (можно почитать в цитируемом посте), все прошло более-менее норм, даже получилось избавиться от polyfill на ranges и fmtlib, потому что в libc++17 format и ranges уже норм.

Из интересного - libc++ перестали поддерживать использование себя с кодом на старых стандартах (с++11 точно, а может, еще и старше тоже). Заметил я это при сборке gcc, для них пришлось оставить libc++16. Благо, сборка это позволяет - https://github.com/pg83/ix/blob/main/pkgs/bin/gcc/10/ix.sh#L4

Самый страшный код, который может встретить разработчик на C++:

struct X {
    X() {
        Initialized = true;
    }

    ~X() {
        Initialized = false;
    }

    auto y() {
        if (Initialized) {
            ...
        }
    }
};

(тут не надо искать подвоха, что y() вызывается в конструкторе или деструкторе, нет)

Будни #bootstrap #gold #gir

Гля чо у меня есть!

pg:~/ix ls .../...-bin-gir/lib/girepository-1.0
cairo-1.0.typelib
DBus-1.0.typelib
DBusGLib-1.0.typelib
fontconfig-2.0.typelib
freetype2-2.0.typelib
Gio-2.0.typelib
GIRepository-2.0.typelib
GL-1.0.typelib
GLib-2.0.typelib
GModule-2.0.typelib
GObject-2.0.typelib
libxml2-2.0.typelib
Vulkan-1.0.typelib
win32-1.0.typelib
xfixes-4.0.typelib
xft-2.0.typelib
xlib-2.0.typelib
xrandr-1.3.typelib

На самом деле, это значит, что у меня случился локальный прорыв в борьбе с gobject introspection (писал про это в https://xn--r1a.website/itpgchannel/1253)

Я сумел собрать g-ir-scanner в статически слинкованный бинарь (напомню, там python, .py скрипты, и модуль _giscanner, который в оригинале идет в виде .so)

Вкратце скетч построения:

* Сборка этого пакета хочет за один присест построить как тулзы, так и _giscanner.so, ну и сгенерить .typelib файлы для всего glib. Мне пришлось это декомпозировать на части. Первым делом я собираю питонячий модуль в виде .a файла, при этом мне нужно убедить родную сборку этого пакета, что у нее уже есть готовые тулзы. Я заменил готовые тулзы на пустой скрипт, который ничего не делает - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/bootstrap/t/ix.sh#L10-L11

* Так как он ничего не делает, то потом надо убедить make install, что нужныке файлы таки сгенерились (они будут пустые) - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/bootstrap/t/ix.sh#L16-L19C20

* Далее я раскидываю поличившиеся артефакты (модуль, и скрипты) правильным образом, как будет ожидать дальнейший шаг - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/ix.sh

* После чего я строю статический конструктор, который зарегистрирует модуль _giscanner в машинерии питона по импорту модулей - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/register/ix.sh#L14 (боже, благолови Сишку, что там можно везде написать void*, без всякого дурацкого манглинга!)

* Дальше я линкую все 3 сущности, которые я описал выше, в один модуль - https://github.com/pg83/ix/blob/main/pkgs/bld/gir/scanner/unwrap/ix.sh#L17-L20, который, по удачному стелению обстоятельств, представляет из себя монобинарь с g-ir-scanner. На ходу пришлось подпатчить скрипт, чтобы модуль _giscanner импортировался корректно.

* Ну а дальше, имея готовый https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L12, и используя фичу сборки этого пакета с внешним g-ir-scanner (для кросс-компиляции), можно построить настоящие .typelib.

Отдельно можно упомянуть:

* https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L22 - если компилятор, который дергает g-ir-scanner, собирает с -O2, то все обламывается на том, что g-ir-scanner не может просканировать заголовки glib, из-за разного поведения G_LIKELY/G_UNLIKELY в дебаге и релизе.

* В процессе работы g-ir-scanner компилирует тулзу, слинкованную со всеми нужнымии библиотеками, и через ldd пытается определить, что же это за библиотеки. Это пришлось зафейкать - https://github.com/pg83/ix/blob/main/pkgs/lib/gi/repository/py/ix.sh#L13-L14

* https://github.com/pg83/ix/blob/main/pkgs/bld/gir/unwrap/ix.sh#L5-L7 - ну и пришлось влинковать в разные программы кучу всякого рода заглушек, которые строят фабрику для dlopen() - https://github.com/pg83/ix/blob/main/pkgs/lib/glib/dl/gobject/ix.sh - вот так, например, выглядит экспорт всех символов из libgobject-2.0.a в мою машинерию.

Короче, это такой маленький шедевр, искусство статической сборки!

(телегу я пока с этим g-ir-scanner не собрал, по причинам, непосредственно с этим текстом не связанным)

Пересобрал. Удивительно, но оно даже работает.

Для того, чтобы бампнуть на последнюю версию, пришлось знатно раскурочить исходники, потому что новые ranges, новый компилятор, и вот это вот все.

Вот, например, набор патчей, связанных с ranges - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L122-L139

Не знаю, современный С++, наверное, уже слишком сложный, чтобы там завелась жизнь компиляторы могли его понимать однозначно.

Наверняка функция, на которую я заменил ranges::contains, компилируется в 100500 раз быстрее, но кому это важно?

https://www.phoronix.com/news/wlroots-Tearing-Control-Merged
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3871?s=09

Я так понимаю, это дает нам объяснение того, почему Hyprland прогнулся под атакой #ddv.

Потому что от Hyprland есть какое-то количество PR в wlroots. И, вот, например, PR по ссылке выше - висел себе 10 месяцев, а тут взял и смержился.

Совпадение?

Вышел python 3.12

Думаю, самая крутая его фишка - это https://docs.python.org/3.12/howto/perf_profiling.html#perf-profiling

Одной строкой - интеграция с perf record/report.

Да, да, в python появился нормальный профайлер!

Тут, конечно, можно устроить срач на тему, что, если вы запускаете профайлер для python, то вы заранее делаете что-то не так. Но, тем не менее, штука очень крутая.

https://www.cppstories.com/2023/monadic-optional-ops-cpp23

Текст про расширения std::optional в c++23.

Чувак, на голубом глазу, считает, что пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#the-c23-way-monadic-extensions лучше читается, чем пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#traditional-approach-with-ifelse-and-optional-c20

Первый пример, конечно, более компактен, но проще читается код по второй ссылке, потому что он:

* немного более рыхлый
* не требует держать в голове дополнительной семантики для своего понимания
* явный control flow

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

https://cstheory.stackexchange.com/questions/53343/recent-advances-in-computer-science-since-2010

Коллега задается вопросом, а что интересного случилось в CS с 2010 года?

А ничего интересного не случилось, инкрементальные улучшения там и тут.

CS, как и многие другие науки, "закончилась", в том смысле, что человеческими мозгами там уже ничего серьезно не накопать. Для како-то существенного прогресса, наверное, нужен более мощный думатель, неважно, алгоритмический, или в виде аппаратного апгрейда человеков.

https://www.bitecode.dev/p/python-312-what-didnt-make-the-headlines#%C2%A7the-performance-let-down

Тут вот коллега пишет, что python 3.12 не быстрее 3.11 на 5%, а довольно значимо медленнее (для теста использовался https://github.com/python/pyperformance).

"You'll notice that 14 tests run faster, but 79 run slower"

Да и даже по wall time всего теста там видно замедление.

Эх, где те (недавние) времена, когда нам обещали 50%-ое ускорение на каждый мажорный релиз?

#fast_python

https://www.phoronix.com/news/Glibc-LD-Nasty-Root-Bug

"We successfully exploited this vulnerability and obtained full root privileges on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, Debian 12 and 13; other distributions are probably also vulnerable and exploitable (one notable exception is Alpine Linux, which uses musl libc, not the glibc)"

#stal/ix, по понятным причинам, данной уязвимости не подвержен.