Ошибка сегментирования сделан дамп памяти

Обновлено: 06.07.2024

Сегментная адресация памяти является одним из подходов к управлению и защите памяти в операционной системе. Для большинства целей она была вытеснена страничной памятью, однако в документациях по традиции используют термин «Ошибка сегментации». Некоторые операционные системы до сих пор используют сегментацию на некоторых логических уровнях, а страничная память используется в качестве основной политики управления памятью.

Содержание

Общие понятия

Сегментная адресация памяти — схема логической адресации памяти компьютера в архитектуре x86. Линейный адрес конкретной ячейки памяти, который в некоторых режимах работы процессора будет совпадать с физическим адресом, делится на две части: сегмент и смещение. Сегментом называется условно выделенная область адресного пространства определённого размера, а смещением — адрес ячейки памяти относительно начала сегмента. Базой сегмента называется линейный адрес (адрес относительно всего объёма памяти), который указывает на начало сегмента в адресном пространстве. В результате получается сегментный (логический) адрес, который соответствует линейному адресу база сегмента+смещение и который выставляется процессором на шину адреса.

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

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

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

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

На аппаратном уровне, неисправность возникает по причине реагирования блока управления памяти (MMU) на неправомерный доступ к памяти.

На уровне операционной системы эта ошибка ловится и сигнал передается в блок «offending process», где эта ошибка обрабатывается:

Причины сегментации

Наиболее распространенные причины ошибки сегментации:

Разыменование нулевых указателей
Попытка доступа к несуществующему адресу памяти (за пределами адресного пространства процесса)
Попытка доступа к памяти программой, которая не имеет права на эту часть памяти
Попытка записи в память, предназначенной только для чтения

Причины зачастую вызваны ошибками программирования, которые приводят к ошибкам связанными с памятью:

Создание операций с разыменованым указателем или создание неинициализированного указателя (указатель, который указывает на случайный адрес памяти)
Разыменование или возложение на освобожденной указатель (использование оборванного указателя, который указывает на память, которая была освобождена или перераспределена).
Переполнение буфера
Переполнение стека
Попытка выполнить программу, которая не компилируется правильно. (Некоторые компиляторы будут выводить исполняемый файл , несмотря на наличие ошибок во время компиляции.)

Пример Segmentation Fault

Рассмотрим пример кода на ANSI C, который приводит к ошибке сегментации вследствие присутствия квалификатора Сonst - type:

Когда программа, содержащая этот код, скомпилирована, строка «hello world» размещена в секции программы с бинарной пометкой «только для чтения». При запуске операционная система помещает её с другими строками и константами в сегмент памяти, предназначенный только для чтения. После запуска переменная s указывает на адрес строки, а попытка присвоить значение символьной константы H через переменную в памяти приводит к ошибке сегментации.

Компиляция и запуск таких программ на OpenBSD 4.0 вызывает следующую ошибку выполнения:

Вывод отладчика gdb:

В отличие от этого, gcc 4.1.1 на GNU/Linux возвращает ошибку ещё во время компиляции:

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

Ещё один способ вызвать ошибку сегментации заключается в том, чтобы вызвать функцию main рекурсивно, что приведёт к переполнению стека:

Обычно, ошибка сегментации происходит потому что: указатель или нулевой, или указывает на произвольный участок памяти (возможно, потому что не был инициализирован), или указывает на удаленный участок памяти. Например:

Теперь разыменование любого из этих указателей может вызвать ошибку сегментации. Также, при использовании массивов, если случайно указать в качестве размера массива неинициализированную переменную. Вот пример:

Такая ошибка не прослеживается G++ при компоновке, но при запуске приложения вызовет ошибку сегментации.

Не всегда программы в 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 обычно содержатся в домашней папке, скрытых подкаталогах с именем программы. Также, настройки и кэш могут содержаться в каталогах

/.cache. Просто удалите папки программы и попробуйте снова ее запустить. Если и это не помогло, вы можете попробовать полностью удалить программу, а потом снова ее установить, возможно, какие-нибудь зависимости были повреждены:

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

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

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

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

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

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

(gdb) attach ваш_pid

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

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

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

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

(gdb) detach
(gdb) quit

Выводы

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

Оцените статью:

(6 оценок, среднее: 5,00 из 5)

Об авторе

7 комментариев

Спасибо, было очень интересно почитать про отладчик.

На самом деле от этого избавится я не могу. Остаётся мне всё сваливать на свой старый компьютер с 1024 мегабайтами озу. Постоянные ошибки сегментирования когда комплимирую какую-либо программу. Чтобы скомплимировать ядро надо по миллиону раз вводить make!! Щас выкину комп и куплю новый и думаю проблема сама разрешится.

Gentoo. cmake 3.14.6. Segmentation fault.
Xeon 2620 v2 24Gb ram

С ошибкой SIGSEGV или так называемой ошибкой сегментации(на самом деле это ошибки обращения с памятью) вы ничё не сможете сделать. если вы юзер, а не разработчик и она возникает в вашей проге. можете только одного не запускать эту прогу удалить её или попытаться обновить, возможно(вовсе не обязательно!) её заметили и исправили. Но вообще лицензионное соглашение по Ubuntu вас предупреждает, что вы пользуетесь системой в которой софт вовсе не обязан работать и никто за это не отвечает. вы это делаете на свой страх и риск! это краткий его перевод. А если вы купили операционку заплатили бабки и заказали техподдержку, то вы тогда уже имеете право обратиться в службу тех поддержки сообщить баг, где и как он возникает и они обязаны не просто испавить его прислав патч, но так же всем таким как вы кто заплатил. Иначе вы имеете право подать на них в суд и они обязаны компенсировать вам убытки. Но это не Ubuntu. Обратная сторона медали свободного по и бесплатных операционок. среди Линуксовых есть AIX(только платная+ техподдержка), SUSE(не путать с Open Suse) и Debian(есть free урезаный вариант и нормальный платный). Это оч серьёзная ошибка краеугольный камень всех программ и работы компа в целом. Если это ломается, то всё летит к чёрту. Конечно они стараюстся и сразу посылать вас не будут. Это их репутация! но вообще дело в програмерах. Щаз стало оч много криворуких. Вот я смотрю на их код и удивляюсь, как можно так безалаберно писать проги! Если бы вы только это видели вы бы не удивились почему всё так плохо работает. Встречаются такие кадры которые всё только портят! ну а что програмеров не хаватет, делать надо много вот и берут всех подряд. А потом начинается. Если конечно это заметили до релиза, то ладно. Но тут всё ещё зависит от тестеров. Если они хорошие то найдут баги вовремя до релиза и исправят. но у нас как бывает. Отдела тестирования нет, сэкономили.. Тестер дай бог 2-3 а то часто 1 вообще. В программе всегда много ошибок. Особенно вначале. все мы ошибаемся, особенно некоторые. Причина? Нехватка мозгов или банально невнимательность. поэтому все проги должны быть тщательнейшим образом оттестированы. только тогда она может быть допущена к релизу. А ещё заказчик подгоняет. Хорошую прогу нельзя написать в спешке. тем более большую. Такие ошибки как оч трудно найти, а если она не всегда воспроизводится, так вообще нереально, Если только случайно наткнёшься. Потому что как бывает один раз вылетела, а второй нет и пошла дальше и норм. Или пошла дальше и всё стало неправильным. с програмой начинают твориться чудеса. это всё та же ошибка с памятью, которая всё портит. Вылететь может не только ваша прога но и вся система. Но даже если она стабильно воспроизводится, то на её поиск может понадобиться дни а может и неделя две кропотливой упорной работы, носящей изнуряющий характер. искать будут всем отделом. но её тогда по крайней мере можно найти. а если нет. то вам поможет только чудо. А уж что сделают после этого с тем кто это сделал я даже не знаю! Вот такие вот они эти ошибки сегментации. Я показал то что там происходит за кадром юзера.

Ошибка сегментирования (сделан дамп памяти)
в обще пишу игрушку с помощью sfml библиотек такая пробема на одном из этапов написания после.

Ошибка сегментирования (сделан дамп памяти)
Доброго времени суток. На текущий момент имеется программа, позволяющая выводить различные вариации.

Ошибка сегментирования (сделан дамп памяти)
В универе задали задание "Реализовать программу определения полного имени файла(подъем по дереву.

Ошибка сегментирования (сделан дамп памяти)
Доброй ночи Подскажите как при программировании на C++ под LINUX (UBUNTU) избавиться от ошибки.

Решение

Падает со stack overflow еще до вызова функции main, скорее всего из-за выделения слишком большого массива (a и b). Выделите его динамически через new.
А еще вы 4 раза одно и тоже значение считаете: pow(2,n). Someone007, спасибо. это действительно помогло. Но теперь уже при n = 26+ выпадает другая ошибка также при выполнении программы. Я полагаю это от того, что слишком большие значения для компьютера. Всё же как никак показательная степень используется. Выпадает ошибка:
Добавлено через 3 минуты
Someone007, а подскажите ещё пожалуйста про функцию clock(), я хочу замерить время работы программы. А эта функция выдаёт не соответствующее время работы самой программы. Т.е. пишет, что проработала 18.5629 секунд, а на самом деле секунд 5.

2^27=0x08000000, 0x08000000*8*2=0x80000000 байт = минимум 2 ГБ памяти (а скорее всего даже больше, зависит от внутреннего устройства std::complex, у меня выделилось 4 ГБ при 27 степени на 64 битной винде и не упало). Это значение в int не укладывается, но падает скорее всего из-за нехватки памяти.

Ошибка сегментирования (сделан дамп памяти)
Проблема в том, что когда я создаю вектор и увеличиваю у него длину путём добавления нового.

Ошибка сегментации(дамп памяти)
Возникает ошибка сегментации. Ошибка связана с методом calcultr(). Не знаю почему так происходит.

Разделяемая память linux, Ошибка сегментирования (сделан дамп памяти)
здравствуйте! помогите с задачей. Четыре дочерних процесса выполняют некоторые циклы .

У меня есть процесс в Linux, в котором возникает ошибка сегментации . Как я могу сообщить ему генерировать дамп ядра при сбое?

Ответ 1

Это зависит от того, какую оболочку вы используете. Если вы используете bash, то команда ulimit управляет несколькими параметрами, относящимися к выполнению программы, например, следует ли сбрасывать ядро. Если вы введете :

ulimit -c unlimited

то это сообщит bash, что ее программы могут сбрасывать ядра любого размера. Вы можете указать размер, например, 52 M вместо неограниченного, если хотите, но на практике в этом нет необходимости, поскольку размер файлов ядра, вероятно, никогда не будет иметь для вас значения. А вот в tcsh необходимо выполнить:

limit coredumpsize unlimited

Ответ 2

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

gcore <pid>

Если же gcore недоступен в вашей системе, тогда:

kill -ABRT <pid>

Не используйте kill -SEGV, так как это часто приводит к вызову обработчика сигналов, что затрудняет диагностику зависшего процесса.

Ответ 3

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

sysctl kernel.core_pattern

или:

cat /proc/sys/kernel/core_pattern

где %e — имя процесса, а %t — системное время. Вы можете изменить его в /etc/sysctl.conf и перезагрузить с помощью sysctl -p. Если файлы ядра не генерируются и далее (проверить это можно с помощью: sleep 10 & и killall -SIGSEGV sleep), проверьте ограничения с помощью команды:

ulimit -a.

Если размер файла ядра ограничен, выполните:

ulimit -c unlimited

чтобы сделать его неограниченным.

Затем снова проверьте, что дамп ядра выполнен успешно — вы увидите "(core dumped)" после индикации ошибки сегментации, как показано ниже:

Segmentation fault: 11 (core dumped)

В Ubuntu дампы ядра обрабатываются Apport и могут быть расположены в /var/crash/. Однако в стабильных релизах он отключен по умолчанию.

Ответ 4

Ответ 5

В /etc/profile закомментируйте строку:

В /etc/security/limits.conf закомментируйте строку:

Выполните команду limit coredumpsize unlimited и проверьте ее с помощью cmd limit:

Для проверки записи файла ядра можно завершить соответствующий процесс командой kill -s SEGV <PID> ( не обязательно, просто в случае, если файл ядра не записывается, это можно использовать как проверку):

После записи corefile убедитесь, что настройки coredump снова отключены в соответствующих файлах.

Ответ 6

Стоит упомянуть, что если у вас установлен systemd, то ситуация немного меняется. Обычно файлы ядра передаются через systemd-coredump(8) посредством значения core_pattern sysctl. Размер rlimit файла ядра, как правило, уже настроен как « неограниченный » .

Затем можно получить дампы ядра с помощью coredumpctl(1).

Хранение дампов ядра и т . д . настраивается coredump.conf(5). Примеры получения файлов ядра есть на man-странице coredumpctl, но вкратце это выглядит следующим образом:

[vps@phoenix]

$ coredumpctl list test_me | tail -1

Sun 2019-01-20 11:17:33 CET 16163 1224 1224 11 present /home/vps/test_me

Получите файл ядра:

[vps@phoenix]

$ coredumpctl -o test_me.core dump 16163

Ответ 7

Для Ubuntu

Создайте

В некоторых ответах предлагается изменить core_pattern. Имейте в виду, что этот файл может быть перезаписан службой apport при перезапуске.
Простая остановка apport может не помочь.
Значение ulimit -c может измениться автоматически. Обязательно проверяйте его регулярно во время настройки создания дампа ядра.

Ответ 8

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Я пишу кроссплатформенную программу на C++ для Windows и Unix. На стороне окна код будет компилироваться и выполняться без проблем. На стороне Unix он будет компилироваться, однако, когда я пытаюсь запустить его, я получаю ошибку сегментации. Моя первоначальная догадка заключается в том, что есть проблема с указателями.

каковы хорошие методологии для поиска и исправления ошибок ошибок сегментации?

скомпилируйте приложение с помощью -g , тогда у вас будут отладочные символы в двоичном файле.

использовать gdb чтобы открыть консоль gdb.

использовать file и передайте двоичный файл вашего приложения в консоль.

использовать run и передать любые аргументы, которые необходимо запустить приложение.

сделайте что-нибудь, чтобы вызвать сегментация Ошибка.

тип bt на gdb консоль, чтобы получить трассировку стека Ошибка Сегментирования.

иногда сама авария не является реальной причиной проблемы - возможно, память была разбита в более ранний момент, но потребовалось некоторое время для коррупции, чтобы показать себя. Проверьте отчет, который имеет много проверок для проблем указателя (включая проверку границ массива). Он скажет вам, где проблема начинается, а не только строка, где происходит сбой.

прежде чем проблема возникнет, старайтесь избегать ее как можно больше:

скомпилировать и запустить код как можно чаще. Будет легче найти неисправную часть.
попробуйте инкапсулировать низкоуровневые / подверженные ошибкам процедуры, чтобы вам редко приходилось работать непосредственно с памятью (обратите внимание на моделирование вашей программы)
поддерживать набор тестов. Имея обзор того, что в настоящее время работает, что больше не работает и т. д., поможет вам выясните, где проблема (ускорение испытаний является возможным решением, я не использую его сам, но документация может помочь понять, какая информация должна отображаться).

использовать соответствующие инструменты для отладки. В Unix:

GDB могу сказать вам, где сбой программы и позволит вам увидеть в каком контексте.
отчет поможет вам обнаружить много памяти ошибки.
~~С GCC вы также можете использовать брызговик~~ С GCC и Clang вы можете использовать Дезинфицирующее Средство Для Адреса / Памяти. Он может обнаружить некоторые ошибки, которые Valgrind не делает, и потеря производительности легче.

наконец, я бы рекомендовал обычные вещи. Чем больше ваша программа читабельна, ремонтопригодна, понятна и аккуратна, тем проще ее будет отлаживать.

в Unix вы можете использовать valgrind для поиска проблем. Это бесплатно и мощно. Если вы хотите сделать это самостоятельно, вы можете перегрузить операторы new и Delete, чтобы создать конфигурацию, в которой у вас есть 1 байт с 0xDEADBEEF до и после каждого нового объекта. Затем отслеживайте, что происходит на каждой итерации. Это может не поймать все (вы не можете даже коснуться этих байтов), но это работало для меня в прошлом на платформе Windows.

Да, есть проблема с указателями. Очень вероятно, что вы используете тот, который не инициализирован должным образом, но также возможно, что вы испортите управление памятью с двойным освобождением или что-то подобное.

чтобы избежать неинициализированных указателей в качестве локальных переменных, попробуйте объявить их как можно позже, желательно (и это не всегда возможно), когда они могут быть инициализированы значимым значением. Убедите себя, что они будут иметь ценность, прежде чем они будут использоваться, изучив код. Если у вас возникли трудности с этим, инициализируйте их константой нулевого указателя (обычно пишется как NULL или 0 ) и проверить их.

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

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

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

используйте строки C++ и классы контейнеров, когда это возможно, вместо C-style строки и массивы. Рассмотрите возможность использования .at(i) , а не [i] , потому что это заставит проверку границ. Посмотрите, можно ли настроить компилятор или библиотеку для проверки границ на [i] по крайней мере в режиме отладки. Ошибки сегментации могут быть вызваны переполнением буфера, которые пишут мусор над совершенно хорошими указателями.

существуют всевозможные "методологии", чтобы избежать проблемы до ее возникновения. Одним из важных является RAII.

кроме того, вы просто должны бросить свои лучшие психические энергии на он.

Читайте также: