Segfaults во многих приложениях

anisart
9 лет, 10 месяцев назад (отредактировано 9 лет, 10 месяцев назад)
Темы: 1
Сообщения: 14
Участник с: 29 мая 2015
Ну в выводе strace зато это есть, хотя это наверно неважно
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
Ну и не поверю я, что gdb не использует glibc. Вот например вывод valgrind, раз gdb не работает
[anisart@k551jm ~]$ valgrind gdb
==17786== Memcheck, a memory error detector
==17786== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17786== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17786== Command: gdb
==17786==
==17786==
==17786== Process terminating with default action of signal 11 (SIGSEGV)
==17786==  Access not within mapped region at address 0x8
==17786==    at 0x400B3E1: _dl_relocate_object (in /usr/lib/ld-2.21.so)
==17786==    by 0x4003F22: dl_main (in /usr/lib/ld-2.21.so)
==17786==    by 0x401643F: _dl_sysdep_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4004D89: _dl_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4000D87: ??? (in /usr/lib/ld-2.21.so)
==17786==  If you believe this happened as a result of a stack
==17786==  overflow in your program's main thread (unlikely but
==17786==  possible), you can try to increase the size of the
==17786==  main thread stack using the --main-stacksize= flag.
==17786==  The main thread stack size used in this run was 8388608.
==17786== Jump to the invalid address stated on the next line
==17786==    at 0x5B6: ???
==17786==    by 0xFFF00047F: ???
==17786==    by 0x4003F22: dl_main (in /usr/lib/ld-2.21.so)
==17786==    by 0x401643F: _dl_sysdep_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4004D89: _dl_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4000D87: ??? (in /usr/lib/ld-2.21.so)
==17786==  Address 0x5b6 is not stack'd, malloc'd or (recently) free'd
==17786==
==17786==
==17786== Process terminating with default action of signal 11 (SIGSEGV)
==17786==  Bad permissions for mapped region at address 0x5B6
==17786==    at 0x5B6: ???
==17786==    by 0xFFF00047F: ???
==17786==    by 0x4003F22: dl_main (in /usr/lib/ld-2.21.so)
==17786==    by 0x401643F: _dl_sysdep_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4004D89: _dl_start (in /usr/lib/ld-2.21.so)
==17786==    by 0x4000D87: ??? (in /usr/lib/ld-2.21.so)
==17786==
==17786== HEAP SUMMARY:
==17786==     in use at exit: 0 bytes in 0 blocks
==17786==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17786==
==17786== All heap blocks were freed -- no leaks are possible
==17786==
==17786== For counts of detected and suppressed errors, rerun with: -v
==17786== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)
Segmentation fault (core dumped)
vasek
9 лет, 10 месяцев назад (отредактировано 9 лет, 10 месяцев назад)
Темы: 47
Сообщения: 11908
Участник с: 17 февраля 2013
anisart
Ну в выводе strace зато это есть, хотя это наверно неважно
Это точно не ошибки
anisart
Вот например вывод valgrind
который еще раз показывает проблему с ld-2.21.so - точнее Access not within mapped region at address 0x8 и что то советовать проблематично, не зная что ты делал и где копался.
Ошибки не исчезают с опытом - они просто умнеют
anisart
9 лет, 10 месяцев назад
Темы: 1
Сообщения: 14
Участник с: 29 мая 2015
Так я и не говорю, что проблема в gdb, chromium или еще каких прогах, которые юзают glibc. Ясен пень, что тут либо косячит ld-2.21.so, либо память (хотя рядом другая инсталяция арча работает нормально и на сегфолты не жалуется).
Вот ради интереса, кто-нибудь с 64 бит напишите вывод ls -la /usr/lib/ld-*
anisart
9 лет, 10 месяцев назад
Темы: 1
Сообщения: 14
Участник с: 29 мая 2015
Госы сдал, нашлось время для проверки памяти. Память тут ни при чем. Также пробовал вытаскивать поочередно планки, ничего не меняется.
Файлы кстати правильного размера. Просто в той системе, которая нормально работает на этом ноуте, была версия 2.21-3, обновил до 2.21-4, продолжает работать. Ничего не понимаю.
lnroman
9 лет, 10 месяцев назад
Темы: 4
Сообщения: 88
Участник с: 15 мая 2015
anisart
Так я и не говорю, что проблема в gdb, chromium или еще каких прогах, которые юзают glibc. Ясен пень, что тут либо косячит ld-2.21.so, либо память (хотя рядом другая инсталяция арча работает нормально и на сегфолты не жалуется).
Вот ради интереса, кто-нибудь с 64 бит напишите вывод ls -la /usr/lib/ld-*

-rwxr-xr-x 1 0 0 161K апр 23 04:40 /usr/lib/ld-2.21.so
lrwxrwxrwx 1 0 0   22 апр 23 13:46 /usr/lib/ld-linux.so.2 -> ../lib32/ld-linux.so.2
lrwxrwxrwx 1 0 0   10 апр 23 04:40 /usr/lib/ld-linux-x86-64.so.2 -> ld-2.21.so
uname -a
Linux naumov 4.0.4-2-ARCH #1 SMP PREEMPT Fri May 22 03:05:23 UTC 2015 x86_64 GNU/Linux

Ты пробывал со старого ядра загрузиться?
lnroman
9 лет, 10 месяцев назад
Темы: 4
Сообщения: 88
Участник с: 15 мая 2015
udp

$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
$ ls /etc/ld.so.conf.d/
fakeroot.conf  lib32-glibc.conf  opencollada.conf
$ cat fakeroot.conf  lib32-glibc.conf  opencollada.conf
/usr/lib/libfakeroot
/usr/lib32
/usr/lib/opencollada
$ ldd /usr/bin/firefox
linux-vdso.so.1 (0x00007ffeded11000)
 libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007ff86efce000)
 libdl.so.2 => /usr/lib/libdl.so.2 (0x00007ff86edca000)
 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff86ea48000)
 libm.so.6 => /usr/lib/libm.so.6 (0x00007ff86e744000)
 libc.so.6 => /usr/lib/libc.so.6 (0x00007ff86e3a2000)
 /lib64/ld-linux-x86-64.so.2 (0x00007ff86f1eb000)
 libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007ff86e18c000)

Появилась такая мысль, что проблема не в ld (точнее не в его целостности), а в том какие библиотеки он пытаеться подцепить.
anisart
9 лет, 10 месяцев назад
Темы: 1
Сообщения: 14
Участник с: 29 мая 2015
Пробовал комментировать пути в /etc/ld.so.conf.d/*.conf - все так же грузится и сегфолтится.
Со старого ядра загрузиться не могу, в этой системе более старого не было, заново например linux-lts поставить не могу - в процессе установки сегфолтится (наверняка какой-нибудь awk используется, а он сейчас падает). Если из соседней системы поставить другое ядро и грузить первую систему с него, то получаем "failed to mount /boot". Нельзя просто так взять и подсунуть другое ядро системе :)
lnroman
9 лет, 10 месяцев назад
Темы: 4
Сообщения: 88
Участник с: 15 мая 2015
anisart
Пробовал комментировать пути в /etc/ld.so.conf.d/*.conf - все так же грузится и сегфолтится.
Со старого ядра загрузиться не могу, в этой системе более старого не было, заново например linux-lts поставить не могу - в процессе установки сегфолтится (наверняка какой-нибудь awk используется, а он сейчас падает). Если из соседней системы поставить другое ядро и грузить первую систему с него, то получаем "failed to mount /boot". Нельзя просто так взять и подсунуть другое ядро системе :)

Ну в полне естевственно как бы фс таб той системы у тебя пакуется в образ ядра.
vasek
9 лет, 10 месяцев назад (отредактировано 9 лет, 10 месяцев назад)
Темы: 47
Сообщения: 11908
Участник с: 17 февраля 2013
anisart
Ну и не поверю я, что gdb не использует glibc
Использует, но своеобразно если вопрос касается ld-2.21.so
Попробую описать (как я это понимаю) использование ld-linux.so.2 и ld-2.21.so (the helper program for shared library executables)
За ошибки и неточности прошу сильно не пинать, а лучшне внести исправления и пояснения — кому то может пригодится.
$ file /usr/lib/ld-linux.so.2
/usr/lib/ld-linux.so.2: symbolic link to ld-2.21.so
$ file /usr/lib/ld-2.21.so
/usr/lib/ld-2.21.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=a02017a8045690095a1c629885614d1b379fba9d, not stripped

и хотя ld-2.21.so относится к категории общих библиотек, на самом деле является исполняемым файлом и отвечает за динамическую загрузку, точнее, считывает информацию из заголовка исполняемого файла и на ее основании определяет, какие библиотеки требуются данному приложению и должны быть загружены.
Точнее, список динамических библиотек приведен в исполняемом файле, например, возьмем gdb
$ readelf -d /usr/bin/gdb
Dynamic section at offset 0x5a2ec4 contains 34 entries:
Тег Тип Имя/Знач
0x00000001 (NEEDED) Совм. исп. библиотека: [libreadline.so.6]
0x00000001 (NEEDED) Совм. исп. библиотека: [libdl.so.2]
0x00000001 (NEEDED) Совм. исп. библиотека: [libncursesw.so.5]
0x00000001 (NEEDED) Совм. исп. библиотека: [libz.so.1]
0x00000001 (NEEDED) Совм. исп. библиотека: [libm.so.6]
0x00000001 (NEEDED) Совм. исп. библиотека: [libguile-2.0.so.22]
0x00000001 (NEEDED) Совм. исп. библиотека: [libpthread.so.0]
0x00000001 (NEEDED) Совм. исп. библиотека: [libpython2.7.so.1.0]
0x00000001 (NEEDED) Совм. исп. библиотека: [libexpat.so.1]
0x00000001 (NEEDED) Совм. исп. библиотека: [liblzma.so.5]
0x00000001 (NEEDED) Совм. исп. библиотека: [libc.so.6]
Приведенные библиотеки считываются, загружаются и попадают в память (по выделенным адресам), откуда они и считываются при запросе .........вот эти то библиотеки и показывает команда $ ldd /usr/bin/gdb.
Дальше возможны, грубо говоря, три типа основных ошибок
1. Ошибка работы ld-2.21.so при считывании информации из исполняемого файла
2. Информация считалась, но какие то библиотеки не могут загрузиться (или их нет вообще или не находятся в пути поиска или битая библиотека)
3. Ошибки адресации памяти
Решение проблем 1-ого и 3-его типа ошибок намного сложнее 2-ого (здесь обычно пишется, что нет файла......ит.п.)
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.

© 2006-2025, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.