LINUX.ORG.RU

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

 , , ,


0

2

Во время апдейта начали падать редко используемые утилиты, в dmesg – ошибки вида

syncqt[19434]: segfault at 1 ip 0000000000000001 sp
00007ffcdabd3a08 error 14 likely on CPU 0 (core 0, socket 0)
Code: Unable to access opcode bytes at 0xffffffffffffffd7.

Gentoo, -march=native, поэтому первая мысль – в GCC что-то напутали с архитектурами. Попробовал пересобирать другим GCC – то же самое.

Куда копать?

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

Ответ: Старая /usr/lib64/libc.so.6 осталась после перехода на новый профиль. Возможно, из-за того, что смена профиля совпала с заменой материнской платы и пересборкой мира под новый процессор. Затронуты, как минимум, несколько пакетов Qt, Tcl и Protobuf.

★★★★★

Последнее исправление: question4 (всего исправлений: 3)
Ответ на: комментарий от Kroz

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

Этим я и занимался.

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

Уже попробовал перейти с 14 на 15. Те же ошибки. Сейчас собираю старые — 11, 12, 13.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

Да, 0x1 это ошибка, а вот 0x00007ffff7a55cc3 - адрес внутри недозагуженной libc.so
Можно попытаться принудительно указать gdb адрес загрузки libc т.к она ещё не прорелоцировалась и gdb её не видит - вероятно, это падает какой-то из конструкторов
Что-то вроде:

add-symbol-file /usr/lib64/libc.so.6 0x7ffff7a15000

Оффсет секции может отличаться, потому не уверен что совсем правильно
Мне кажется немного странным это:
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 

Не разные ли это версии libc? Не говорит ли preserved-libs о том. что оставил старую libc из-за каких-то бинарей? Может, ты долго не обновлялся и словил баг из-за старого профиля (split-usr?)
Проверь - /usr/lib64/libc.so.6 и /lib64/libc.so.6 - один и тот же файл?

gentoo
location: /usr/portage

Да у вас тут наверняка древний профиль

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 2)
Ответ на: комментарий от question4

Пересобрал оба

Оба чего? Судя по бэктрейсу, пересобирать надо было glibc

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

Это константа 1, которую кто-то использовал в качестве адреса. Кто и зачем — пока неясно. Но на мискомпиляцию пока не очень похоже.

annulen ★★★★★
()
Ответ на: комментарий от mittorn

Не говорит ли preserved-libs о том. что оставил старую libc из-за каких-то бинарей?

Не говорит, проверял. Хотя из-за прерванного апдейта там много пакетов, и значительная часть — из старого слота KDE. Почищу на всякий случай.

Проверь - /usr/lib64/libc.so.6 и /lib64/libc.so.6 - один и тот же файл?

А вот это не проверял, и файлы оказались разные, спасибо. /usr/lib64/libc.so.6 датирован сентябрём, и в пакет sys-libs/glibc не входит. Удалил. Пересобрал syncqt. Не падает. Спасибо.

question4 ★★★★★
() автор топика
Ответ на: комментарий от mittorn

как так вообще получилось, что в системе 2 разных libc, да ещё и одна из них не принадлежит ни к какому пакету?

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

question4 ★★★★★
() автор топика
Ответ на: комментарий от firkax

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

Спасибо за это замечание. После очередной пересборки qtbase удалось запустить КДЕ, и вторую половину темы уже писал из фаерфокса вместо elinks.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

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

Скорее всего gpm копирует результат рендеринга. А ядерная консоль по legacy причинам использует рендеринг в шрифт из 256 или 512 символов. В котором очень много что совмещено для того чтоб покрыть достаточно много разных алфавитов.

GPFault ★★★
()
Ответ на: комментарий от question4

ну вот, любое изменение в обход системного менеджера чревато, даже новые файлы. Особенно опасно это на source-based системах, когда система сборки может молча залинковаться на левую библиотеку, создав скрытую ошибку, которая появится после обновления основной. Это ещё повезло что оно сегфолтнулось сразу и только в определённых приложениях, а могло и дальше оставаться незамеченным, но в какой-то момент сломаь, например, init...

mittorn ★★★★★
()
Ответ на: комментарий от GPFault

ядерная консоль по legacy причинам использует рендеринг в шрифт из 256 или 512 символов. В котором очень много что совмещено для того чтоб покрыть достаточно много разных алфавитов.

Да, в ней «п» и «π» выглядят одинаково.

question4 ★★★★★
() автор топика
Ответ на: комментарий от mittorn

Это ещё повезло что оно сегфолтнулось сразу и только в определённых приложениях, а могло и дальше оставаться незамеченным, но в какой-то момент сломаь, например, init…

Большинство старых бинарников на новом процессоре гарантировано сегфолтились. Их я выловил ещё в ноябре.

Что не сегфолтилось, я искал find-ом. Но неправильно понял русский перевод man find, перепутал минуты с сутками, поэтому много пропустил. Сейчас qfile -o $(find /bin /usr/{bin/,games/,include/,lib*/,sbin/,x86_64-pc-linux-gnu/} /lib* -mtime +137 -type f) выловил:
десятки файлов glibc,
libreadline,
ncurses,
OpenRC,
libcap,
sys-auth/passwdqc,
net-misc/dhcpcd,
Qt5Core и qtdbus-5,
libavutil.so 2013 года,
возможно связанные с ним blas и lapack завязанные на закрытую реализацию OpenCl 2018 года,
остатки zscaler,
какие-то файлы GCC 2013 и 2017 годов,
библиотеки Питона 3.2,
какие-то cracklib_dict,
прочие бинарники, оставшиеся от сборки в чруте…

question4 ★★★★★
() автор топика