Gnome control center ошибка сегментирования

#
4 года, 2 месяца назад

Темы:

47

Сообщения:

11604

Участник с: 17 февраля 2013

dancerla2
gdb — нет такого файла или каталога
а вообще вывод там большой

Я привел просто в качестве примера … если есть желание — изучай, нет желания — забудь.
gdb — это отладчик, который нужно установить, тогда после большого вывода будет ожидать строка ввода (gdb) , где нужно вписать bt, сокращенное от backtrace, чтобы увидеть вывод backtrace , а потом проанализировать этот вывод или подебажить дальше …
НО лучше не морочь себе голову и забудь об этом.

Ошибки не исчезают с опытом — они просто умнеют

wau

#
4 года, 2 месяца назад

(отредактировано

4 года, 2 месяца назад)

Темы:

137

Сообщения:

1031

Участник с: 11 октября 2013

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

vasek

#
4 года, 2 месяца назад

Темы:

47

Сообщения:

11604

Участник с: 17 февраля 2013

wau
Увы, либра таки падает,

я не замечаю, последние дни частенько работаю с документами, но ни одного падения.

Ошибки не исчезают с опытом — они просто умнеют

median

#
4 года, 2 месяца назад

(отредактировано

4 года, 2 месяца назад)

median avatar

Темы:

4

Сообщения:

140

Участник с: 17 августа 2016

Проблема была с gnome-control-center что описана выше вызывала ошибку в виде Ошибка сегментирования (стек памяти сброшен на диск)
, хорошо, нашли временное решение, я же решил переустановить арч опять, но уже с кде по умолчанию, запускаю хром, он стартует, но если захочешь переключится с одной вкладки на другую происходит лаг, секунды 4 тормозит браузер, драйвера все установлены, понимаю что в 2 клика меняются DE, много ума не надо сменить DE, но меня смутило что после запуска через терминал хрома вылетела та же ошибка что и в гноме Ошибка сегментирования (стек памяти сброшен на диск),
Сново переустановил арч, и точно такая же проблема Ошибка сегментирования (стек памяти сброшен на диск). Я в замешательстве. Пока переустанавливал, решил что скрипт написать быстрее всетаки, чем ручками, но какой в этом толк, если чистая система сыпет ошибками Ошибка сегментирования (стек памяти сброшен на диск). Запустил федору в лайве, все нормально ничего не тормозит не лагает.
P.S Комп на fx8320e 16gb озу, ssd, видеокарта rx570 4gb
Но если запускаю firefox то ничего не тормозит, опять же некоторые приложения в кедах так же вызывали ошибку Ошибка сегментирования (стек памяти сброшен на диск).

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

vasek

#
4 года, 2 месяца назад

(отредактировано

4 года, 2 месяца назад)

Темы:

47

Сообщения:

11604

Участник с: 17 февраля 2013

median
точно такая же проблема Ошибка сегментирования (стек памяти сброшен на диск).

Это сообщение (итоговое, чем все завершилось) одно и тоже, а причины (виновник), ведущие к этому, могут быть совершенно разные.
А чтобы найти виновника нужно анализировать.

PS — имхо, если бы виновником был какой то конкретный пакет/приложение, то проблема была бы глобальная (наблюдалась у всех). В данном случае это скорее всего локальная проблема.

EDIT 1 — кстати, в части установки — совсем недавно ставил Arch (KDE) новое дарование и все работает — Как все таки установить Арч Линукс? без ошибок?

Ошибки не исчезают с опытом — они просто умнеют

median

#
4 года, 2 месяца назад

median avatar

Темы:

4

Сообщения:

140

Участник с: 17 августа 2016

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

vs220

#
4 года, 2 месяца назад

Темы:

22

Сообщения:

8109

Участник с: 16 августа 2009

median
прекрасно знаю

Вам просто обьяснили что ваша проблема с хромом не связана с этой темой. Создавайте отдельную тему

Richard_Hendricks

#
4 года, 2 месяца назад

Richard_Hendricks avatar

Темы:

0

Сообщения:

4

Участник с: 28 февраля 2019

+1 Не открывается gnome-control-center
даже на чистоустановленном арче параметры запустилось, при нажатии вкладки подробности(где сведения о системе и т.д.) слетело и больше не запустилось

Linux User Group

vs220

#
4 года, 2 месяца назад

(отредактировано

4 года, 2 месяца назад)

Темы:

22

Сообщения:

8109

Участник с: 16 августа 2009

Richard_Hendricks
даже на чистоустановленном арче

Вам же уже давал Васек ссылку.
Баг гнома, на багтрекере есть.
уже даже и патч есть .
А свежеустановленный или нет арч тут роли не играет

median

#
4 года, 2 месяца назад

(отредактировано

4 года, 2 месяца назад)

median avatar

Темы:

4

Сообщения:

140

Участник с: 17 августа 2016

Можно обвлять glib, правда лучше удалить, gnome-control-center и поставить заново, тем не менее я обновился, больше не вылетает.


0

3

Привет решил попробовать статью с cobedy о безопасности системы,теперь не работает control center и док панель
https://codeby.net/threads/kak-nastroit-kali-linux-v-plane-bezopasnosti-i-anonimnosti.61383/page-7#posts

gnome-control-center

(gnome-control-center:2358): dconf-WARNING **: 03:44:21.713: failed to commit changes to dconf: Соединение закрыто
Error creating rfkill proxy: (null)

(gnome-control-center:2358): dconf-WARNING **: 03:44:23.445: failed to commit changes to dconf: Соединение закрыто
zsh: segmentation fault gnome-control-center

запускается только из терминала и вылетает. Пожалуйста огромная просьба. Любителям потешиться и «самым умным» можно ни чего не отвечать? Уже начитался.

действия были сделаны до пункта с ключем самоуничтожения.

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

nome-control-center start

(gnome-control-center:7224): dconf-WARNING **: 21:10:15.206: failed to commit changes to dconf: Соединение закрыто

(gnome-control-center:7224): cc-window-WARNING **: 21:10:15.320: Could not find settings panel «start»
Error creating rfkill proxy: (null)
zsh: segmentation fault gnome-control-center start

На мой взгляд, есть гораздо лучшее решение этой проблемы, кроме избавления от полезного хранилища, которое мне лично нравится. Что мне помогло, так это установление основного приоритета репо. Вы можете видеть, что есть два репозитория, доступных для gnome-control-center пакет и система 76 теперь используется с apt-cache policy gnome-control-center команда:

gnome-control-center:
  Installed: 1:3.34.1-1ubuntu2pop1~1571679625~19.10~ef2ab1f
  Candidate: 1:3.34.1-1ubuntu2pop1~1571679625~19.10~ef2ab1f
  Version table:
 *** 1:3.34.1-1ubuntu2pop1~1571679625~19.10~ef2ab1f 500
        500 http://ppa.launchpad.net/system76/pop/ubuntu eoan/main amd64 Packages
        100 /var/lib/dpkg/status
     1:3.34.1-1ubuntu2 500
        500 http://de.archive.ubuntu.com/ubuntu eoan/main amd64 Packages

Смотрите те 500s? Это приоритет репо по умолчанию, и он тот же. Давайте сделаем основной репо более высоким приоритетом (я нахожусь на Ubuntu 19.10 под кодовым названием eoanпожалуйста, используйте вместо этого кодовое имя вашего дистрибутива):

    $ apt-cache policy | grep o=Ubuntu | grep c=main | grep a=eoan,
     release v=19.10,o=Ubuntu,a=eoan,n=eoan,l=Ubuntu,c=main,b=i386
     release v=19.10,o=Ubuntu,a=eoan,n=eoan,l=Ubuntu,c=main,b=amd64

Что release ... part — это своего рода фильтр, который вы можете использовать для придания репо другого приоритета. Создайте и отредактируйте (как корень) файл с именем /etc/apt/preferences.d/main_repo_priority выглядеть так:

    Package: *
    Pin: release v=19.10,o=Ubuntu,a=eoan,n=eoan,l=Ubuntu,c=main,b=amd64
    Pin-Priority: 1001

И теперь, наконец, переустановите gnome-control-center:

    sudo apt install --reinstall gnome-control-center

И дважды проверьте, что установлена ​​правильная версия:

    $ apt-cache policy gnome-control-center
     gnome-control-center:
       Installed: 1:3.34.1-1ubuntu2
       Candidate: 1:3.34.1-1ubuntu2
       Version table:
          1:3.34.1-1ubuntu2pop1~1571679625~19.10~ef2ab1f 500
             500 http://ppa.launchpad.net/system76/pop/ubuntu eoan/main amd64                                                          Packages
     *** 1:3.34.1-1ubuntu2 1001
           1001 http://de.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
            100 /var/lib/dpkg/status

well, the strange thin is when I start gnome with gdm it does work as expected, but not in i3-gnome

Here the gdb output:

gdb gnome-control-center
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gnome-control-center...
(No debugging symbols found in gnome-control-center)
(gdb) r
Starting program: /usr/bin/gnome-control-center 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe9c02700 (LWP 15476)]
[New Thread 0x7fffe9401700 (LWP 15477)]
[New Thread 0x7fffe2100700 (LWP 15482)]
[New Thread 0x7fffe18ff700 (LWP 15483)]
[New Thread 0x7fffe1051700 (LWP 15485)]
[New Thread 0x7fffcffff700 (LWP 15499)]

Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
0x00005555556725c0 in cc_display_config_set_minimum_size ()
(gdb) c
Continuing.
Couldn't get registers: No existe el proceso.
Couldn't get registers: No existe el proceso.
(gdb) [Thread 0x7fffcffff700 (LWP 15499) exited]
[Thread 0x7fffe1051700 (LWP 15485) exited]
[Thread 0x7fffe18ff700 (LWP 15483) exited]
[Thread 0x7fffe2100700 (LWP 15482) exited]
[Thread 0x7fffe9401700 (LWP 15477) exited]
[Thread 0x7fffe9c02700 (LWP 15476) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
q

And here the journald log when I run gnome-control-center:

oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): LG Electronics LG FULL HD (CRT-0): connected
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): LG Electronics LG FULL HD (CRT-0): 400.0 MHz maximum pixel clock
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0):
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-0: disconnected
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0):
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-1: disconnected
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-1: Internal TMDS
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
oct 22 08:36:37 GibyArch /usr/lib/gdm-x-session[13970]: (--) NVIDIA(GPU-0):
oct 22 08:36:37 GibyArch kernel: gnome-control-c[18837]: segfault at 0 ip 000056320c0d55c0 sp 00007fffc5855278 error 4 in gnome-control-center[56320c002000+103000]
oct 22 08:36:37 GibyArch kernel: Code: 08 31 c0 ff 15 49 29 31 00 e9 48 ff ff ff ff 15 ce 23 31 00 66 0f 1f 44 00 00 48 8b 07 ff a0 d0 00 00 00 0f 1f 80 00 00 00 00 <48> 8b 07 ff a0 c8 00 00 00 0f 1f 80 00 00 00 00 48 8b 05 29 92 31
oct 22 08:36:37 GibyArch kernel: audit: type=1701 audit(1571726197.865:135): auid=1000 uid=1000 gid=100 ses=6 pid=18837 comm="gnome-control-c" exe="/usr/bin/gnome-control-center" sig=11 res=1
oct 22 08:36:37 GibyArch audit[18837]: ANOM_ABEND auid=1000 uid=1000 gid=100 ses=6 pid=18837 comm="gnome-control-c" exe="/usr/bin/gnome-control-center" sig=11 res=1
oct 22 08:36:37 GibyArch systemd[1]: Started Process Core Dump (PID 18844/UID 0).
oct 22 08:36:37 GibyArch audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@8-18844-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
oct 22 08:36:37 GibyArch kernel: audit: type=1130 audit(1571726197.905:136): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@8-18844-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
oct 22 08:36:38 GibyArch systemd-coredump[18845]: Process 18837 (gnome-control-c) of user 1000 dumped core.
                                                  
                                                  Stack trace of thread 18837:
                                                  #0  0x000056320c0d55c0 cc_display_config_set_minimum_size (gnome-control-center)
                                                  #1  0x000056320c0dd6e2 n/a (gnome-control-center)
                                                  #2  0x000056320c0dde91 n/a (gnome-control-center)
                                                  #3  0x00007f9c83003d3a g_closure_invoke (libgobject-2.0.so.0)
                                                  #4  0x00007f9c82ff188e n/a (libgobject-2.0.so.0)
                                                  #5  0x00007f9c82ff598a g_signal_emit_valist (libgobject-2.0.so.0)
                                                  #6  0x00007f9c82ff67f0 g_signal_emit (libgobject-2.0.so.0)
                                                  #7  0x000056320c0d557c n/a (gnome-control-center)
                                                  #8  0x00007f9c830e7c24 n/a (libgio-2.0.so.0)
                                                  #9  0x00007f9c830ed447 n/a (libgio-2.0.so.0)
                                                  #10 0x00007f9c8309cc15 n/a (libgio-2.0.so.0)
                                                  #11 0x00007f9c830e7c24 n/a (libgio-2.0.so.0)
                                                  #12 0x00007f9c830e7c59 n/a (libgio-2.0.so.0)
                                                  #13 0x00007f9c82f172cf g_main_context_dispatch (libglib-2.0.so.0)
                                                  #14 0x00007f9c82f19211 n/a (libglib-2.0.so.0)
                                                  #15 0x00007f9c82f19251 g_main_context_iteration (libglib-2.0.so.0)
                                                  #16 0x00007f9c830ca9de g_application_run (libgio-2.0.so.0)
                                                  #17 0x000056320c0023fe main (gnome-control-center)
                                                  #18 0x00007f9c83205153 __libc_start_main (libc.so.6)
                                                  #19 0x000056320c00244e _start (gnome-control-center)
                                                  
                                                  Stack trace of thread 18843:
                                                  #0  0x00007f9c832d7e9d syscall (libc.so.6)
                                                  #1  0x00007f9c82eca11b g_cond_wait_until (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f47f63 n/a (libglib-2.0.so.0)
                                                  #3  0x00007f9c82eef13b n/a (libglib-2.0.so.0)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
                                                  
                                                  Stack trace of thread 18841:
                                                  #0  0x00007f9c832d7e9d syscall (libc.so.6)
                                                  #1  0x00007f9c82eca11b g_cond_wait_until (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f47f63 n/a (libglib-2.0.so.0)
                                                  #3  0x00007f9c82eef13b n/a (libglib-2.0.so.0)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
                                                  
                                                  Stack trace of thread 18840:
                                                  #0  0x00007f9c832d29ef __poll (libc.so.6)
                                                  #1  0x00007f9c82f19180 n/a (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f19251 g_main_context_iteration (libglib-2.0.so.0)
                                                  #3  0x00007f9c6d4cbe5e n/a (libdconfsettings.so)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
                                                  
                                                  Stack trace of thread 18842:
                                                  #0  0x00007f9c832d7e9d syscall (libc.so.6)
                                                  #1  0x00007f9c82eca11b g_cond_wait_until (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f47f63 n/a (libglib-2.0.so.0)
                                                  #3  0x00007f9c82eef13b n/a (libglib-2.0.so.0)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
                                                  
                                                  Stack trace of thread 18838:
                                                  #0  0x00007f9c832d29ef __poll (libc.so.6)
                                                  #1  0x00007f9c82f19180 n/a (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f19251 g_main_context_iteration (libglib-2.0.so.0)
                                                  #3  0x00007f9c82f192a2 n/a (libglib-2.0.so.0)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
                                                  
                                                  Stack trace of thread 18839:
                                                  #0  0x00007f9c832d29ef __poll (libc.so.6)
                                                  #1  0x00007f9c82f19180 n/a (libglib-2.0.so.0)
                                                  #2  0x00007f9c82f1a123 g_main_loop_run (libglib-2.0.so.0)
                                                  #3  0x00007f9c83087b48 n/a (libgio-2.0.so.0)
                                                  #4  0x00007f9c82ef5c11 n/a (libglib-2.0.so.0)
                                                  #5  0x00007f9c814bf4cf start_thread (libpthread.so.0)
                                                  #6  0x00007f9c832dd2d3 __clone (libc.so.6)
oct 22 08:36:38 GibyArch systemd[1]: systemd-coredump@8-18844-0.service: Succeeded.
oct 22 08:36:39 GibyArch kernel: audit: type=1131 audit(1571726198.979:137): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@8-18844-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
oct 22 08:36:38 GibyArch audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@8-18844-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Не всегда программы в Linux запускаются как положено. Иногда, в силу разных причин программа вместо нормальной работы выдает ошибку. Но нам не нужна ошибка, нам нужна программа, вернее, та функция, которую она должна выполнять. Сегодня мы поговорим об одной из самых серьезных и непонятных ошибок. Это ошибка сегментации Ubuntu. Если такая ошибка происходит только один раз, то на нее можно не обращать внимания, но если это регулярное явление нужно что-то делать.

Конечно, случается эта проблема не только в Ubuntu, а во всех Linux дистрибутивах, поэтому наша инструкция будет актуальна для них тоже. Но сосредоточимся мы в основном на Ubuntu. Рассмотрим что такое ошибка сегментирования linux, почему она возникает, а также как с этим бороться и что делать.

Что такое ошибка сегментации?

Ошибка сегментации, Segmentation fault, или Segfault, или SIGSEGV в Ubuntu и других Unix подобных дистрибутивах, означает ошибку работы с памятью. Когда вы получаете эту ошибку, это значит, что срабатывает системный механизм защиты памяти, потому что программа попыталась получить доступ или записать данные в ту часть памяти, к которой у нее нет прав обращаться.

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

Допустим, в вашей системе есть 6 Гигабайт оперативной памяти, каждой программе нужно выделить определенную область, куда будет записана она сама, ее данные и новые данные, которые она будет создавать. Чтобы дать возможность каждой из запущенных программ использовать все шесть гигабайт памяти был придуман механизм виртуального адресного пространства. Создается виртуальное пространство очень большого размера, а из него уже выделяется по 6 Гб для каждой программы. Если интересно, это адресное пространство можно найти в файле /proc/kcore, только не вздумайте никуда его копировать.

Выделенное адресное пространство для программы называется сегментом. Как только программа попытается записать или прочитать данные не из своего сегмента, ядро отправит ей сигнал SIGSEGV и программа завершится с нашей ошибкой. Более того, каждый сегмент поделен на секции, в некоторые из них запись невозможна, другие нельзя выполнять, если программа и тут попытается сделать что-то запрещенное, мы опять получим ошибку сегментации Ubuntu.

Почему возникает ошибка сегментации?

И зачем бы это порядочной программе лезть, куда ей не положено? Да в принципе, незачем. Это происходит из-за ошибки при написании программ или несовместимых версиях библиотек и ПО. Часто эта ошибка встречается в программах на Си или C++. В этом языке программисты могут вручную работать с памятью, а язык со своей стороны не контролирует, чтобы они это делали правильно, поэтому одно неверное обращение к памяти может обрушить программу.

Почему может возникать эта ошибка при несовместимости библиотек? По той же причине — неверному обращению к памяти. Представим, что у нас есть библиотека linux (набор функций), в которой есть функция, которая выполняет определенную задачу. Для работы нашей функции нужны данные, поэтому при вызове ей нужно передать строку. Наша старая версия библиотеки ожидает, что длина строки будет до 256 символов. Но программа была обновлена формат записи поменялся, и теперь она передает библиотеке строку размером 512 символов. Если обновить программу, но оставить старую версию библиотеки, то при передаче такой строки 256 символов запишутся нормально в подготовленное место, а вот вторые 256 перезапишут данные программы, и возможно, попытаются выйти за пределы сегмента, тогда и будет ошибка сегментирования linux.

Что делать если возникла ошибка сегментирования?

Если вы думаете, что это ошибка в программе, то вам остается только отправить отчет об ошибке разработчикам. Но вы все-таки еще можете попытаться что-то сделать.

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

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

sudo apt update
sudo apt full-upgrade

Если это не помогло, нужно обнулить настройки программы до значений по умолчанию, возможно, удалить кэш. Настройки программ в Linux обычно содержатся в домашней папке, скрытых подкаталогах с именем программы. Также, настройки и кэш могут содержаться в каталогах ~/.config и ~/.cache. Просто удалите папки программы и попробуйте снова ее запустить. Если и это не помогло, вы можете попробовать полностью удалить программу, а потом снова ее установить, возможно, какие-нибудь зависимости были повреждены:

sudo apt remove пакет_программы
sudo apt autoremove
sudo apt install пакет_программы

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

Когда вы все это выполнили, скорее всего, проблема не в вашем дистрибутиве, а в самой программе. Нужно отправлять отчет разработчикам. В Ubuntu это можно сделать с помощью программы apport-bug. Обычно Ubuntu предлагает это сделать сразу, после того как программа завершилась с ошибкой сегментирования. Если же ошибка сегментирования Ubuntu встречается не в системной программе, то вам придется самим искать разработчиков и вручную описывать что произошло.

Чтобы помочь разработчикам решить проблему, недостаточно отправить им только сообщение что вы поймали Segmentation Fault, нужно подробно описать проблему, действия, которые вы выполняли перед этим, так чтобы разработчик мог их воспроизвести. Также, желательно прикрепить к отчету последние функции, которые вызывала программа (стек вызовов функций), это может очень сильно помочь разработчикам.

Рассмотрим, как его получить. Это не так уж сложно. Сначала запустите вашу программу, затем узнайте ее PID с помощью команды:

pgrep программа

Дальше запускаем отладчик gdb:

sudo gdb -q

Подключаемся к программе:

(gdb) attach ваш_pid

После подключения программа станет на паузу, продолжаем ее выполнение командой:

(gdb) continue

segfault

Затем вам осталось только вызвать ошибку:

segfault1

И набрать команду, которая выведет стек последних вызовов:

(gdb) backtrace

Вывод этой команды и нужно отправлять разработчикам. Чтобы отключиться от программы и выйти наберите:

(gdb) detach
(gdb) quit

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

Выводы

Теперь у вас есть приблизительный план действий, что нужно делать, когда появляется ошибка сегментирования сделан дамп памяти ubuntu. Если вы знаете другие способы решить эту проблему, напишите в комментариях!

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Creative Commons License

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Понравилась статья? Поделить с друзьями:
  • Global python ошибка
  • Global freeze ошибка высокое давление
  • Global freeze gf35 ошибки
  • Global cfg not found igo ошибка
  • Glo ошибки индикация