всеобщий segmentation fault

Не понял почему в приведенной мною выше ссылке советуют понизить libxcursor (1.1.14-2 — 1.1.14-1). Я бы понизил glibc (2.19-5 - 2.19-4). Оба обновлялись в мае. Вот мои рассуждения
Твои данные для clementine
.......................
#0 0xb5eb2d30 in __GI__IO_file_stat () from /usr/lib/libc.so.6
#1 0xb5ea7797 in __GI__IO_file_doallocate () from /usr/lib/libc.so.6
….........................................................
Та как ты не привел инфу по firefox, пришлось смотреть какие он использует динамические библиотеки — вот они
linux-gate.so.1 (0xb7772000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7734000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb772f000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7639000)
libm.so.6 => /usr/lib/libm.so.6 (0xb75ed000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb75cf000)
libc.so.6 => /usr/lib/libc.so.6 (0xb740d000)
И как видим присутствуе libc.so.6, правда если быть точнее, то это не библиотека как таковая, а указатель на другую библиотеку
$ ls -l /usr/lib/libc.so.6
lrwxrwxrwx 1 root root 12 май 16 10:22 /usr/lib/libc.so.6 -> libc-2.19.so
Смотрим далее
$ pacman -Qo /usr/lib/libc-2.19.so
/usr/lib/libc-2.19.so принадлежитglibc 2.19-5
-------------------------------------------------------
А потому я попробовал бы для начала понизить glibc (с 2.19-5 на 2.19-4)
Ну а не получится, попробуй рекомендации приведенной ссылки.
Возможно, я и не прав, могу ошибаться, но информацию ты предоставил скудную.
Ошибки не исчезают с опытом - они просто умнеют
Всем большое спасибо, в особенности vasek!
Откатил glibc, но это не устранило проблему. Затем уже откатил libxcursor и пока полёт нормальный.

Как мне при последующих обновления избежать обновления этой библиотеке?
текущая версия
[pavel@desk ~]$ pacman -Qi libxcursor
Name           : libxcursor
Version        : 1.1.14-1
Description    : X cursor management library
Architecture   : i686
URL            : http://xorg.freedesktop.org/
Licenses       : custom
Groups         : None
Provides       : None
Depends On     : libxfixes  libxrender
Optional Deps  : None
Required By    : gtk2  gtk3  xorg-xsetroot
Optional For   : qt4
Conflicts With : None
Replaces       : None
Installed Size :  64,00 KiB
Packager       : Andreas Radke <andyrtr@archlinux.org>
Build Date     : Чт 30 май 2013 22:34:06
Install Date   : Вс 06 июл 2014 15:39:22
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By   : None

ps: тестового ничего не использовал
pavelt
Как мне при последующих обновления избежать обновления этой библиотеке?
Читай до конца Wiki - лучше обе, рус+англ
Ошибки не исчезают с опытом - они просто умнеют
pavelt, чисто технический вопрос — чем генерировал backtrace.
Вопрос задан не из-за любопытства и не хочется заводить новую тему.
В связи с недавним нововедением в systemd, а именно, systemd-coredumpctl, нам посоветовали создать файл /etc/sysctl.d/50-coredump.conf. И, как я понял, дампы памяти будут сбрасываться в journal. Имеется возможность, прямо из журнала как просмотра списка дампов, так и заброска дампов в gdb. Что вообщем то неплохо, можно сказать даже очень хорошо.
Но в связи с этим мне не совсем ясен вопрос с размером core file size (по умолчанию он равен 0) — похоже его размер сейчас не важен, а вместо него будет иметь значение размер самого журнала. Ну и также можно убирать все другие настройки по сбросу дампа из конфигов, если такие настройки были.
Поэтому у меня вопрос к специалистам — правильно ли я все понимаю, если нет, то прошу разъяснить этот момент.
И вдобавок, сбрасываются ли у кого-нибудь дампы памяти в journal — не хочется лишний раз экспериментировать и провоцировать segmentation fault искусственно.
Запрос списка дампов (на моем примере)
$ systemd-coredumpctl list
No coredumps found
Ошибки не исчезают с опытом - они просто умнеют
[v@arch ~]$ systemd-coredumpctl list
TIME                                         PID   UID   GID SIG EXE
             Пн 2014-01-06 23:47:11 MSK    361  1000   100  11 /usr/bin/thunar
             Пн 2014-01-06 23:58:45 MSK    366  1000   100  11 /usr/bin/thunar
             Вт 2014-01-07 16:42:59 MSK    570  1000   100  11 /usr/bin/thunar
             Вт 2014-01-28 20:27:24 MSK   2471  1000   100  11 /usr/bin/thunar
             Пт 2014-01-31 08:10:18 MSK   1600  1000   100   6 /usr/bin/qupzilla
             Пт 2014-01-31 11:28:03 MSK    796  1000   100  11 /usr/bin/qupzilla
             Вс 2014-02-02 07:42:24 MSK   1054  1000   100  11 /usr/bin/thunar
             Пн 2014-02-03 11:52:54 MSK    562  1000   100  11 /usr/bin/thunar
             Пт 2014-02-07 18:47:01 MSK    563  1000   100  11 /usr/bin/thunar
             Пт 2014-02-21 00:07:42 MSK    588  1000   100  11 /usr/bin/thunar
             Пн 2014-02-24 15:15:54 MSK   5767  1000   100  11 /usr/bin/thunar
             Пт 2014-03-14 16:53:48 MSK    593  1000   100  11 /usr/bin/thunar
             Ср 2014-03-19 12:57:45 MSK   1359  1000   100  11 /usr/bin/thunar
             Чт 2014-04-10 19:51:58 MSK    877  1000   100  11 /usr/bin/qupzilla
             Вт 2014-04-22 17:36:05 MSK   2714  1000   100  11 /usr/bin/thunar
             Ср 2014-05-07 19:39:28 MSK    955  1000   100   6 /usr/bin/qupzilla
             Чт 2014-06-12 11:09:53 MSK    726  1000   100  11 /usr/bin/thunar
             Чт 2014-06-12 11:58:53 MSK   1044  1000   100  11 /home/v/Загрузки/
             Чт 2014-06-12 11:59:26 MSK   1062  1000   100  11 /home/v/Загрузки/
             Чт 2014-06-12 12:07:13 MSK   1165  1000   100  11 /home/v/Загрузки/
             Вс 2014-06-15 22:52:28 MSK   1344  1000   100  11 /usr/bin/thunar
             Пн 2014-06-16 22:50:31 MSK    622  1000   100  11 /usr/bin/thunar
             Вс 2014-06-22 18:42:19 MSK    669     0     0   6 /usr/bin/gsmartco
lines 2-24/24 (END)
teplovoz, спасибо за ответ. Значит systemd-coredumpctl работает.
Несколько вопросов, если не в тягость
1. Создавал ли ты файл /etc/sysctl.d/50-coredump.conf и что включил в него дополнительно.
2. Какой размер журнала установлен.
3. Работает ли $ systemd-coredumpctl gdb
UPD.........пробовал ли разбираться со своими упавшими приложениями
PS........... проверил, все работает нормально, дампы пишутся. $ systemd-coredumpctl gdb - по умолчанию обрабатывает последний по времени дамп.
$ systemd-coredumpctl gdb
TIME PID UID GID SIG EXE
Вс 2014-07-06 15:18:39 IST 896 1000 100 11 /home/user/test_dump/test
............................
Core was generated by `/home/user/test_dump/test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x080483d9 in a ()
(gdb) bt
#0 0x080483d9 in a ()
#1 0x080483fb in main ()
(gdb)
И все-таки все больше уважения к systemd
Ошибки не исчезают с опытом - они просто умнеют
pavelt
Откатил glibc, но это не устранило проблему. Затем уже откатил libxcursor и пока полёт нормальный.
Как мне при последующих обновления избежать обновления этой библиотеке?
Там надо было все прочитать:
I can confirm (at least on my system) `sudo rm /usr/share/icons/default` appears to have worked.
и причину закрытия бага. При обновлении проблем не будет.
naszar
и причину закрытия бага. При обновлении проблем не будет.
А я как всегда невнимательный, вторую половину просмотрел по диагонали, а концовку вообще не читал - вот что значит не моя ошибка.
Не первый раз замечаю, что у Вас зоркий глаз.
Ошибки не исчезают с опытом - они просто умнеют
Хоть выше уже и ответили...

vasek
pavelt, чисто технический вопрос — чем генерировал backtrace.
Вопрос задан не из-за любопытства и не хочется заводить новую тему.
генерировал gdb

systemd-coredumpctl list
ничего не выдаёт, хоть /etc/sysctl.d/50-coredump.conf существует, но пустой.

naszar
Там надо было все прочитать:
и причину закрытия бага. При обновлении проблем не будет.
Спасибо. Так и сделал. :)
 
Зарегистрироваться или войдите чтобы оставить сообщение.