Внезапные сегфолты

Если есть что-то легко воспроизводимое, то запускать по gdb и ловить падение

Если нет, то можно попробовать записывать корки, если что-то наловится, то можно будет корку через gdb открыть и посмотреть бэктрейс

memtest

Что я вижу

ip 0000000000000001

в начале адресного пространства лежат нулевые страницы. Error 14 general protection #GP. Странно должно быть #PF у него номер 13.

Code: Unable to access opcode bytes at 0xffffffffffffffd7

Ещё более странно. Но предположу как это могло быть. Ты наверно стал обновлять какую нибудь libc и под удар попал код работающий с vdso. Редко используемые утилиты находятся обычно в режиме ожидания таймера, довольно много их состояния в этом случае может быть завязано на vdso. Сложно без телепатов ставить диагноз

А почему после апдейта?

memtest

Ругается на отсутствие видеорежима(?) Пока запустил memtester (юзерспейсный)

Всё наоборот, gp=13, а pf появился позже, только в 32-бит процах, у него номер больше, возможно 14 это как раз он.

Просмотр подобных сообщений говорит, что это происходит при компиляции qt и обычно означает мусор в исходниках или header файлах. Рекомендуется полностью очистить Qt source package. Если не поможет, копать syncqt, это perl script. Косяк может быть в нём самом или версиях несовместимости.

Не понял, они падают прямо во время апдейта а потом перестают, или же во время апдейта начались их падения и ты до сих пор не знаешь как эти падения прекратить?

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

Tы нaвepнo cтaл oбнoвлять ĸaĸyю нибyдь libc

Да, libc обновилась, обновление qt упало, появилось предупреждение от libc перезапустить все программы или рестартовать. Я ребутнулся, иксы отказались грузиться.

А, так это сборочная прога от компиляции этих обновлений? Я думал у него что-то полезное падает после того как он обновился.

иксы отказались грузиться.

Так лог ошибки нужен. И может быть их пересобрать надо?

Какая ОС то? В тегах нет.

Ну может быть я уже давно на ассемблере не пишу. Я уж тем более номера исключений на память не помню. Помню что они как раз рядом. Для меня это выглядит как побитая память vdso. Один из вариантов ядро ещё старая версия ядра вот libc уже новая

Peĸoмeндyeтcя πoлнocтью oчиcтить Qt source package.

Как это сделать? Стереть исходники и распаковать заново? При установке portage так и делает.

syncqt, этo perl script

У меня это бинарный ELF64.

Ну тут вообще то даже логов толком нет

Ecли ecть чтo-тo лeгĸo вocπpoизвoдимoe, тo зaπycĸaть πo gdb и лoвить πaдeниe

$ gdb --args /usr/lib64/qt6/libexec/syncqt

...

(gdb) disas
�� No function contains program counter for selected frame.
(gdb) bt
#0  0x0000000000000001 in ?? ()
#1  0x00007ffff7a55cc3 in ?? ()
#2  0x00007ffff7ff0923 in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00000000069682ac in ?? ()
#4  0x00000000069682ac in ?? ()
#5  0x00007ffff7fd32fa in _dl_lookup_direct ()
   from /lib64/ld-linux-x86-64.so.2
#6  0xffffffffffffffff in ?? ()
#7  0xfffffffffffffff8 in ?? ()
#8  0x25cdddf481ddfd00 in ?? ()
#9  0x00001a09cd304a05 in ?? ()
Backtrace stopped: Cannot access memory at address 0xffffffffffffffd9

Что из этого можно извлечь?

Опыта работы с gdb у меня нет.

git clean -dfx

Но вообще гентушники поопытнее меня должны что-нибудь сказать. Здесь явно проблема несовместимых частей, часть Qt осталась связана с предыдущей libc. Разруливать такие вещи вручную всегда больно.

Эта сборочная прога – первый попавшийся пример. И без этих сборочных прог обновление застряло на полдороге.

Зачем git, если все исходники из тарболла?

Согласен, данные скудные, но есть один очень важный факт - проблема в syncqt. Я предположил, что компилировалось Qt. Так и оказалось. Ну значит сюда и копать.

Я не знаю, что последнее было успешным, нужно возвращаться в ту точку. Если из tarball-a, вероятность битого tarball-а нулевая. Возможно растарить и начать сборку по новой.

Чтобы превратить вопросики в названия функций и номера строчек в коде, нужна дебажная инфа. См. https://wiki.gentoo.org/wiki/Debugging

Лог иксов: https://paste.gentoo.zip/IZEG1rKL

Он libc на ходу поменял. Сам же пишет. Значит в районе vdso поплыли смещения

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

Это я понял. Я и сказал что это очень нехорошо, особенно раз перегрузился. Сейчас только один вариант, компилировать по новой то, что недокомпилировал.

Запоротое обновление. Кстати: идея добавить в дистры режим лютого отката. Чтоб ключевые файлы восстанавливал вались из архива а дальше АПТ или кто там получал возможность запуститься и выйти на какой то снапшот

Это позже. Сейчас нужно текущую проблему решать.

Новости при обновлениях не забываешь читать?

Новостей в eselect news с января не было. За последний год libc там не упоминалась.

Ceйчac тoльĸo oдин вapиaнт, ĸoмπилиpoвaть πo нoвoй тo, чтo нeдoĸoмπилиpoвaл.

Для компиляции нужны эти самые сегфолтящиеся утилиты.

Что при этом в /proc/{pid}/maps по этим адресам?
Возможно, стоит пересобрать glibc с дебагом. Вообще, glibc по хорошему всегда должна быть собрана с отладочными символами, без них во многих случаях невозможно получить нормальный стектрейс даже по багам, не связанным с libc. Так же без них не работают утилиты вроде valgrind (но с -march=native оно вероятно всё равно не заработает)

могло ли быть такое, что эти утилиты случйно влинковали часть libc статически и оно теперь конфликтует?

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

очевидно, install сначала убирает старый файл, а только потом пишет новый. Иначе бы при обновлении libc его маппинги стали невалидными и процессы бы попадали с sigbus, либо же, если секция не уменьшилась - с SIGILL.
В случае с обновлением же там даже имя файла другое, так что горячее пеперисывание бинарника маловероятно

предупреждение о перезапуске процессов там чтобы избежать загрузки 2 libc в один процесс. Т.е если существующий процесс попытатется сделать dlopen и загрузит что-то от новой libc или её саму - он может внезапно упасть и лучше заблаговременно его перезапустить. Для процессов, не дёргающих dlopen (в т.ч неявно) опасности нет

мoглo ли быть тaĸoe, чтo эти yтилиты cлyчйнo влинĸoвaли чacть libc cтaтичecĸи и oнo тeπepь ĸoнфлиĸтyeт?

В смысле? При сборке утилиты в неё попал код старой libc, который теперь конфликтует с новой? Вряд ли. Я её уже с новой libc несколько раз пересобирал (с разными отладочными опциями) – падает одинаково.

@maxcom, в цитате все «п» стали «π»

ну или что-то, от чего оно зависит.
Повторюсь, смотри в maps и ищи что может это вызвать.
Пересобирай с дебагом.
Ну и там где дебага нет, смотри disasemble на тех фреймах, где ещё адекватные адреса

glibc обновлять, если это обновление не пришло в твоей ветке дистрибьютива… Десять раз бы подумал, прежде чам такое делать. Базовая библиотека по сути. К тому же, со временем стало очевидно - чем более новая версия, тем заметней, что обратной совместимости всё меньше.

@maxcom, в цитате все «п» стали «π»

В БД оно в таком виде сохранено, возможно @question4 что-то странное сделал. Если будет повторяться то заведите топик в linux-org-ru plz.

возможно question4 что-то странное сделал.

Koπиπacтил этoт тeĸcт в elinks.

UPD2: Это происходит, если скопировать текст мышью в ядерной консоли, затем попереключаться между консолями и вставить в Elinks.

Сейчас поэкспериментирую с другими программами.

UPD3: Если просто переключиться в другую ядерную консоль, и сделать echo в файл, там тоже русские «п» заменятся на «пи». То ли глюки gpm, то ли моей системы.

Для топика по Gentoo вопиюще мало информации.

$ grep CPU_FLAGS_X86 /etc/portage/make.conf
$ emerge --info

И, да, memtest надо бы пройти.

vdso не так работает

Такое хоть и крайне редко, но бывает
Например, поставил обновляться 500+ пакетов, оборвалось на половине (причина не важна)
Через пару дней решил продолжить, сделал --sync (за это время обновился libc, который собирается первым), продолжил, и может вот такое вылезти, хотя в Генте и есть механизм пересборки зависимостей при обновлении libc, но раз в раз пару лет - случается

vdso маппится в процессы ядром. Как glibc на него может повиляить?

В любом случае не помешает:

$ emerge --depclean -av

$ emerge -1 gcc
$ gcc-config -l
$ gcc-config <цифра обозначающая последнюю доступную версию>
$ env-update
$ source /etc/profile
$ emerge -1 libtool
$ emerge -1 gcc

$ cd /usr/src/linux
$ make -j <колличество ядер минус два> bziImage modules modules_install install

$ emerge -ave --keep-going world --exclude 'gentoo-sources'

P. S. Перед всем этим желательно бы сделать это, но вероятно не для твоего случая:

$ emerge --sync ; eix-update
$ emerge -avuND --keep-going world --exclude 'gentoo-sources'

memtest надо бы пройти.

Memtest при загрузке пишет, что будет работать вслепую. Как я понимаю, не может инициализировать видео. Как его пересобрать, чтобы работал нормально?

Прогнал 26 раз юзерспейсный memtester — ничего не поймал.

emerge –info

https://paste.gentoo.zip/od5hFXwS

CPU_FLAGS_X86

CPU_FLAGS_X86="aes avx f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 xop" либо CPU_FLAGS_X86="aes avx avx2 avx512_bf16 avx512_bitalg avx512_vbmi2 avx512_vnni avx512_vp2intersect avx512_vpopcntdq avx512bw avx512cd avx512dq avx512f avx512ifma avx512vbmi avx512vl avx_vnni bmi1 bmi2 f16c fma3 mmx mmxext pclmul popcnt rdrand sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 vpclmulqdq"

Если есть что-то легко воспроизводимое, то запускать по gdb и ловить падение

Пересобрал оба с nostrip и -ggdb3:

Reading symbols from /usr/lib64/qt6/libexec/syncqt...
(gdb) run
Starting program: /usr/lib64/qt6/libexec/syncqt 

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000001 in ?? ()
(gdb) disassemble 
❌ No function contains program counter for selected frame.
(gdb) bt
#0  0x0000000000000001 in ?? ()
#1  0x00007ffff7a55cc3 in ?? ()
#2  0x00007ffff7ff1923 in ?? () from /lib64/ld-linux-x86-64.so.2
#3  0x00000000069682ac in ?? ()
#4  0x00000000069682ac in ?? ()
#5  0x00007ffff7fd45ca in _dl_lookup_direct (map=0x7fffffffcf90, undef_name=0x7ffff7ffe2f0 "", new_hash=4294967288, version=0x7ffff7ff1915 "GLIBC_PRIVATE", 
    version_hash=157536133) at dl-lookup-direct.c:87
#6  0xffffffffffffffff in ?? ()
#7  0x00007ffff7ffe2f0 in ?? ()
#8  0xe33ce2c23c6b4800 in ?? ()
#9  0x000045e7d1e66d54 in ?? ()
Backtrace stopped: Cannot access memory at address 0xffffffffffffffd9
(gdb) 

$ cat /proc/30239/maps 
555555554000-555555559000 r--p 00000000 08:01 271422645                  /usr/lib64/qt6/libexec/syncqt
555555559000-555555588000 r-xp 00005000 08:01 271422645                  /usr/lib64/qt6/libexec/syncqt
555555588000-555555591000 r--p 00034000 08:01 271422645                  /usr/lib64/qt6/libexec/syncqt
555555591000-555555592000 r--p 0003d000 08:01 271422645                  /usr/lib64/qt6/libexec/syncqt
555555592000-555555593000 rw-p 0003e000 08:01 271422645                  /usr/lib64/qt6/libexec/syncqt
7ffff7958000-7ffff7967000 r--p 00000000 08:01 272080545                  /lib64/libm.so.6
7ffff7967000-7ffff79d8000 r-xp 0000f000 08:01 272080545                  /lib64/libm.so.6
7ffff79d8000-7ffff7a13000 r--p 00080000 08:01 272080545                  /lib64/libm.so.6
7ffff7a13000-7ffff7a14000 r--p 000ba000 08:01 272080545                  /lib64/libm.so.6
7ffff7a14000-7ffff7a15000 rw-p 000bb000 08:01 272080545                  /lib64/libm.so.6
7ffff7a15000-7ffff7a39000 r--p 00000000 08:01 233308978                  /usr/lib64/libc.so.6
7ffff7a39000-7ffff7b9d000 r-xp 00024000 08:01 233308978                  /usr/lib64/libc.so.6
7ffff7b9d000-7ffff7bf2000 r--p 00188000 08:01 233308978                  /usr/lib64/libc.so.6
7ffff7bf2000-7ffff7bf6000 r--p 001dd000 08:01 233308978                  /usr/lib64/libc.so.6
7ffff7bf6000-7ffff7bf8000 rw-p 001e1000 08:01 233308978                  /usr/lib64/libc.so.6
7ffff7bf8000-7ffff7c00000 rw-p 00000000 00:00 0 
7ffff7c00000-7ffff7c97000 r--p 00000000 08:01 267625654                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
7ffff7c97000-7ffff7de8000 r-xp 00097000 08:01 267625654                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
7ffff7de8000-7ffff7e74000 r--p 001e8000 08:01 267625654                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
7ffff7e74000-7ffff7e85000 r--p 00273000 08:01 267625654                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
7ffff7e85000-7ffff7e86000 rw-p 00284000 08:01 267625654                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.so.6.0.34
7ffff7e86000-7ffff7e8a000 rw-p 00000000 00:00 0 
7ffff7f3d000-7ffff7f42000 rw-p 00000000 00:00 0 
7ffff7f42000-7ffff7f46000 r--p 00000000 08:01 267625634                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
7ffff7f46000-7ffff7f6a000 r-xp 00004000 08:01 267625634                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
7ffff7f6a000-7ffff7f6e000 r--p 00028000 08:01 267625634                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
7ffff7f6e000-7ffff7f6f000 r--p 0002c000 08:01 267625634                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
7ffff7f6f000-7ffff7f70000 rw-p 0002d000 08:01 267625634                  /usr/lib/gcc/x86_64-pc-linux-gnu/15/libgcc_s.so.1
7ffff7f70000-7ffff7fc0000 r--p 00000000 08:01 19464293                   /etc/ld.so.cache
7ffff7fc0000-7ffff7fc2000 rw-p 00000000 00:00 0 
7ffff7fc2000-7ffff7fc6000 r--p 00000000 00:00 0                          [vvar]
7ffff7fc6000-7ffff7fc8000 r-xp 00000000 00:00 0                          [vdso]
7ffff7fc8000-7ffff7fc9000 r--p 00000000 08:01 272080265                  /lib64/ld-linux-x86-64.so.2
7ffff7fc9000-7ffff7ff0000 r-xp 00001000 08:01 272080265                  /lib64/ld-linux-x86-64.so.2
7ffff7ff0000-7ffff7ffb000 r--p 00028000 08:01 272080265                  /lib64/ld-linux-x86-64.so.2
7ffff7ffb000-7ffff7ffd000 r--p 00033000 08:01 272080265                  /lib64/ld-linux-x86-64.so.2
7ffff7ffd000-7ffff7ffe000 rw-p 00035000 08:01 272080265                  /lib64/ld-linux-x86-64.so.2
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 
7ffffffdd000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

Я правильно понимаю, что 0x0000000000000001 ничему не соответствует и это — явная ошибка?

Да, это означает a = *p, в то время как p = NULL.

Что при этом в /proc/{pid}/maps по этим адресам?

Внезапные сегфолты (комментарий)