Баг с экраном.

[Sabaka]

Здрасьте, ось linuxcnc-wheezy 2.7.8
Проблема: при извлечении усб флешки из компа, экран линукса выдал такое (см. фото), не знаю как это связано но вылезало такое два раза при извлечении флехи из порта, извлекал по правилам, не торопился.
Особенность: при этом сам комп и станок работали, с клавы я мог двигать моторами и судя по всему манипулировать самой осью без проблем. Выключить при этом грамотно не смог, пришлось дергать вилку в обоих случаях.
Вопрос: что это такое?

[flyu]

Это ругается ядро операционной системы. На комбинацию клавиш ALT+F1, ALT+F2, ... ALT+F9 реагирует? Вздутые конденсаторы на материнке и в блоке питания есть? Попробуй проверить память и диск на наличие ошибок, проверь температуру проца и памяти. Возможно перегревается. Продуй сжатым воздухом системник и блок питания.

[Serg]

Вопрос: что это такое?

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

[Sabaka]

С материнкой все в порядке, вздутий нет, с БП тоже проблем на вид нет. Это случалось на двух разных материнках с разными БП, разной оперативкой и одним и тем же хардом. Компы не перегревались. Эту версию думаю можно исключить.
Комбинации клавиш не пробовал, если еще раз вылетит так, то проверю.
УП загруженная с флешки это исключено, я как раз УП перекинул как обычно на комп и сразу извлек флеху, обязательно предварительно размонтировав в обоих случаях. И сразу вылетало это при физическом выдергивании.
Отмотать экран я так понимаю нереально а вот может есть логи какие то, где можно посмотреть причину сбоя?

[Serg]

Отмотать экран я так понимаю нереально а вот может есть логи какие то, где можно посмотреть причину сбоя?

Если комп реагирует на кнопки, то попробуй Shift-PgUp. Ну или в системных логах поищи эти строчки...

[Sabaka]

Кнопки 100% работали и комп на них реагировал.
В общем попробую для начала поискать инфу с багом на досуге)

[netraider]

Вопрос: что это такое?

судя по наличию в стеке vfs_read - кто-то пытается читать из какого-то файла. Это и приводит к падению.
1) возможно флешка таки не размониторовалась.
2) возможно что извлечение флешки приводит к попытке чтения (системой) некоторого файла с системного диска. а там bad sector.
3) или это просто баг ( вот здесь что-то похожее нагуглилось - http://www.serverphorums.com/read.php?12,104517 )

[Serg]

судя по наличию в стеке vfs_read - кто-то пытается читать из какого-то файла.

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

[netraider]

это программа hardinfo упала пытаясь что-то преобразовать в строку, только вот результат получился длинее выделенного под него буфера

нет. указатель переданный в strlen указывал на место в адресном пространстве, по которому не было фактических данных. После детектирования этого ядро должно было отмапить часть файла в АП процесса, но ничего из этого не получилось, "unable to handle kernel paging request at 0xfb7b749c". По этому адресу должен был находиться какой-то строковый литерал (или format string для vsprintf, или один из ее аргументов).

[Serg]

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

Какая разница-то? Факт в том, что процесс попытался получить доступ к памяти, которая не принадлежит этому процессу - ядро его и пристрелило за это.
Только это не причина, а лишь следствие проблемы. Причина вероятнее всего именно с выдёргивании неразмонтированной флешки.

P.S. А strlen была вызвана из vsnprintf - т.е. оно таки что-то преобразовывало в строку. И если глянуть исходник функции vsnprintf в glibc, то можно заметить, что подобная реакция (падение на strlen) возможна именно когда функции vsnprintf передаётся буфер, размером меньше получаемого результата...

[netraider]

Какая разница-то? Факт в том, что процесс попытался получить доступ к памяти, которая не принадлежит этому процессу - ядро его и пристрелило

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

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

[339713.274364] [<ffffffff8107e875>] ? __debug_show_held_locks+0x25/0x30
[339713.281325] [<ffffffff81041225>] __schedule_bug+0x65/0x70
[339713.287316] [<ffffffff81340f95>] thread_return+0x6e8/0x823
[339713.293399] [<ffffffff81043a93>] __cond_resched+0x13/0x30
[339713.299403] [<ffffffff81341148>] _cond_resched+0x28/0x30
[339713.305316] [<ffffffff810ee76b>] unmap_vmas+0x93b/0x9d0
[339713.311048] [<ffffffff810f369e>] exit_mmap+0xde/0x190
[339713.316663] [<ffffffff8104d544>] mmput+0x54/0x110
[339713.321950] [<ffffffff810525f2>] exit_mm+0x102/0x130
[339713.327427] [<ffffffff81053d3d>] do_exit+0x18d/0x7d0
[339713.332959] [<ffffffff8100f917>] oops_end+0xa7/0xb0
[339713.338417] [<ffffffff8102dd3a>] no_context+0x15a/0x250
[339713.344180] [<ffffffff8102dfcb>] __bad_area_nosemaphore+0xdb/0x1c0
[339713.350933] [<ffffffff8102e14e>] bad_area_nosemaphore+0xe/0x10
[339713.357352] [<ffffffff8102e471>] do_page_fault+0xb1/0x2e0
[339713.363307] [<ffffffff813444ef>] page_fault+0x1f/0x30
[339713.368957] [<ffffffff811c19ee>] ? strnlen+0xe/0x40
[339713.374504] [<ffffffff811c381f>] string+0x3f/0xd0
[339713.379777] [<ffffffff811c4552>] vsnprintf+0x242/0x580
[339713.385527] [<ffffffff811328ce>] seq_printf+0x7e/0xc0
[339713.391146] [<ffffffff8105818e>] ? r_start+0x2e/0x70
[339713.396689] [<ffffffff813440d1>] ? _read_lock+0x41/0x50
[339713.402514] [<ffffffff8105818e>] ? r_start+0x2e/0x70
[339713.408053] [<ffffffff81058077>] r_show+0x77/0x80
[339713.413306] [<ffffffff81132ea0>] ? seq_read+0x0/0x3c0
[339713.418871] [<ffffffff8113310b>] seq_read+0x26b/0x3c0
[339713.424474] [<ffffffff81132ea0>] ? seq_read+0x0/0x3c0
[339713.430102] [<ffffffff8116ba8a>] proc_reg_read+0x7a/0xb0
[339713.435986] [<ffffffff81115f44>] vfs_read+0xc4/0x190
[339713.443127] [<ffffffff81116420>] sys_read+0x50/0x90
[339713.448527] [<ffffffff8100b2eb>] system_call_fastpath+0x16/0x1b

И в исходниках strlen нет никаких вызовов page_fault, этот механизм работает _иначе_ (особенности реализации cтраничной организации виртуальной памяти)

И если глянуть исходник функции vsnprintf в glibc, то можно заметить, что подобная реакция (падение на strlen) возможна именно когда функции vsnprintf передаётся буфер, размером меньше получаемого результата...

Падение _внутри_ strlen, на vsnprintf можно даже не смотреть. Буфер недостаточного размера здесь не при чем.

В данном конкретном случае ядро обнаружило что не может получить актуальные данные, переданные по указателю в strlen, потому что фактически эти данные находятся на диске, и для их получения необходимо отобразить в память (механизм shared memory) некоторый блок. Но файл по факту отсутствует, данные получить невозможно. Если бы файл был на месте, то все было бы ок - страница данных отображается в память, управление возвращается в strlen и все работает дальше как задуманно.


Это все похоже на попытку запуска исполняемого файла с флешки или компакт-диска (либо это какой-то callback, регистрируемый в ядре и возвращающий данные, которые находятся на диске). Запустили, вытащили носитель, что будет дальше? если весь модуль успел отмапиться в память (и не успел сбросится в swap) - то все будет ок. иначе - будет падение с аналогичной диагностикой. В windows к слову можно принудительно указать спец.флаг при линковке - в этом случае в swap файле создается копия испольняемого модуля, который потом и запускается (первоначально специально сделано для приложений, запускаемых с CD-ROM).

[Serg]

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

Ссылка вообще совсем про другое падение...

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

Это все похоже на попытку запуска исполняемого файла с флешки или компакт-диска

Нет, это произошло именно в стандартной программе hardinfo (находящейся в /usr/bin), которая выполнялась с PID 4332 - об этом написано прямым текстом в "листинге".

[netraider]

Ссылка вообще совсем про другое падение...

юзермодные стеки совпадают на 99%. Причина там таже самая.

В данном случае никаких подкачек небыло

Прямым текстом написано - "Unable to handle kernel paging request.."

была попытка обращения к памяти по адресу в регистре EAX

Да, в EAX находится указатель, который был передан в strlen.

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

Этот участок памяти не отмаплен в ОЗУ. И именно в этом случае запускается процесс подкачки. И этот процесс абсолютно прозрачен для пользователя. Вот, например (опять windows, но механизмы одинаковы):

Не смотря на количесво этих page faults - все работает, ничего не падает (это 'minor fault' - отсуствие данных было детектировано и исправлено) . И это нормально. но вот если по какой-либо причине невозможно загрузить в ОЗУ запрошенную страницу (с диска) - то произойдет то, что мы наблюдаем ('major fault'). Причин может быть несколько - с адресом "не связан" никакой блок памяти - чтение по случайному адресу например. Был "связан", но по факту отсутствует - вот как раз пример с внешним носителем. и т.п. В всех случаях выполняется попытка подкачки. Где у нас храняться статические массивы? как правило в сегменте данных. Где находится этот сегмент? на диске. Чтобы получить его содержимое - этот участок памяти должен находится в ОЗУ. Кто и когда его туда "загружает"? Вот как раз этот механизм подкачки. Для исполняемых файлов в подавляющем большинстве случаев используется отображение файлов в память (в частности если три приложения используют один и тот же shared модуль (dll например), то памяти в ОЗУ будет "выделено" только столько, сколько занимает один этот модуль, а не три). Также может использоваться swap файл и т.д.
Более подробно можно почитать, например здесь - http://www.informit.com/articles/articl ... 1&seqNum=5

об этом само ядро там написало.

Вот код, который это написал:

printk(KERN_ALERT "Unable to handle kernel paging request at "
"%016lx\n", address);

И находится он (внезапно) в функции do_page_fault, которая вызывается ядром.

netraider писал(а):
Это все похоже на попытку запуска исполняемого файла с флешки или компакт-диска
Нет, это произошло именно в стандартной программе

Ключевое слово выделил

[Serg]

Прямым текстом написано - "Unable to handle kernel paging request.."

В Linux память выделяется страницами, отсюда и слово page.
Статические переменные находятся в сегменте данных, обычные переменные в стеке. Обращение к данным в файле через mmap() тоже использует буфер в сегменте данных. Страницы сегментов данных и стека могут быть высвоплены только на swap раздел - сильно сомневаюсь, что этот раздел был активирован на флешке/cdrom...
Сегменты кода не свопятся в принципе - они изначально есть на диске.

И это нормально. но вот если по какой-либо причине невозможно загрузить в ОЗУ запрошенную страницу (с диска) - то произойдет то, что мы наблюдаем ('major fault').

Менеджер памяти (vm) в Linux работает в контексте ядра и для процессов совсем не заметен. В случае если он не сможет обеспечить процесс памятью, то процесс получит ошибку в случае запроса доп.памяти (malloc), либо просто "зависнет" со статусом Z (zombie) до тех пор пока не получит свой кусок памяти обратно из свопа.

Вобщем чтоб не разводить тут ликбез про VM в Linux советую самостоятельно почитть соотв. доку - там довольно подробно всё описано.

[netraider]

Сегменты кода не свопятся в принципе - они изначально есть на диске.

И как же они с диска выполняются-то так сразу? Правильный ответ - вкратце описан в цитате в самом низу.

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

И это нормально. но вот если по какой-либо причине невозможно загрузить в ОЗУ запрошенную страницу (с диска) - то произойдет то, что мы наблюдаем ('major fault').

Менеджер памяти (vm) в Linux работает в контексте ядра и для процессов совсем не заметен. В случае если он не сможет обеспечить процесс памятью, то процесс получит ошибку в случае запроса доп.памяти (malloc), либо просто "зависнет" со статусом Z (zombie) до тех пор пока не получит свой кусок памяти обратно из свопа.

Вобщем чтоб не разводить тут ликбез про VM в Linux советую самостоятельно почитть соотв. доку - там довольно подробно всё описано.

Пару постов назад разговор был про vsprintf и не корректный размер буфера, теперь уже "ликбез про VM"...
Тут нужен ликбез по устройству виртуальной памяти в защищенном режиме безотносительно ОС. Механизм трансляция виртуальных адресов, TLB и т.п. "Менеджер памяти", malloc - это уже другой уровень, это все работает в виртуальном адресном пространстве. Подкачка страниц и связанные веще - это уровень ниже.

по ссылке выше:

int handle_mm_fault( mm, vma, addr, access type);

The routine takes four arguments: mm is a pointer to the mm structure of the address space in which the fault occurred, vma is a pointer to the vm-area that covers the page that is being accessed, addr is the virtual address that caused the fault, and access type is an integer indicating the type of access (read, write, or execute). The return value is an indication of how the page fault was handled. A return value of 1 signifies that the fault was handled successfully and that it should be counted as a minor fault. This means that the page installed was already in memory, e.g., because the page is in use by another process as well. A return value of 2 signifies that the fault was also handled successfully, but that it should be counted as a major fault because the page had to be read from disk, e.g., from a file or swap space. A value of 0 signifies that the page fault could not be handled properly and that the kernel should send a bus error signal (SIGBUS) to the process. Finally, a negative return value signifies that the kernel is completely out of memory and that the faulting process should be terminated immediately.

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

[Serg]

И как же они с диска выполняются-то так сразу?

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

теперь уже "ликбез про VM"...

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

"Менеджер памяти", malloc - это уже другой уровень, это все работает в виртуальном адресном пространстве.

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

[netraider]

Не надо фантазировать, я не говорил, что сегменты кода выполняются с диска.

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

Ты ж сам полез в механизм работы VM

Что там лезть-то, на самом первом скриншоте все написано - "Unable to handle kernel paging request"
Терминология тебе непонятна (kernel paging request), ок, попытался рассказать, но:
Все аргументы, обясняющие то что произошло - тобой игнорируются.
Показал откуда это сообщение появляется (имена функций) - ты игнорируешь...
Рассказал про page fault - ты игнорируешь...
Нашел и показал аналогичный стек, в котором присутствует стек ядра - ты игнорируешь... (этого вообще должно быть достаточно чтобы закрыть разговор)
Вместо конструктивного диалога я вижу последовательное игнорирование всех аргументов. Поэтому не вижу смысла в продолжении разговора.

Ну а откуда ж берётся память в этом виртуальном адресном пространстве, от сырости чтоль образуется?..

Ссылку я уже давал, надо там на первую страницу перейти и прочитать http://www.informit.com/articles/article.aspx?p=29961
Все последовательно описано. И про отображение страниц, и про подкачку, и про page faults, TLB, про то как объем адресного простраства может превышаеть объем доступного ОЗУ и прочее. И про то, что происходит при попытке процесса получить доступ на read/write/execute по некоторому адресу и т.п.
Про сырость, malloc и некорректный размере буффера в vsprintf ничего фантазировать не нужно.

[Serg]

Что должно произойти перед тем, как его можно будет выполнить?

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

Я тебе другой вопрос задал.

Не имеющий отношения к теме - неудачная попытка съехать с темы...
Почитай хотя-бы так называемый "gorman book", чтоб понимать о чём речь...

Что там лезть-то, на самом первом скриншоте все написано - "Unable to handle kernel paging request"

Там-же написано, что это произошло в системной программе hardinfo, которая лежит в /usr/bin, а не на флешке или cdrom'е. И не понятно к чему все эти слова про выделении памяти, хотел меня поразить умными словами? Не получилось - я в ядре Linux хорошо ориентируюсь ещё с версии 0.97.

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

Он вообще не имеет отношения к теме. В твоём листинге видно, что после отстрела strlen начинает работать "отладочный" код, который добавил компилятор по опции "-g". Подтверждение этому легко находится в книжках по gdb.

Поэтому не вижу смысла в продолжении разговора.

Как-то слабо верится...

[netraider]

Что должно произойти перед тем, как его можно будет выполнить?

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

Как именно? как проиходит создание АП для процесса? relocations кто будет выполнять? страницы с флагами write + execute не "отбрасываются" и не загружаются повторно "из файла".

Что там лезть-то, на самом первом скриншоте все написано - "Unable to handle kernel paging request"

Там-же написано, что это произошло в системной программе hardinfo, которая лежит в /usr/bin, а не на флешке или cdrom'е.

ну так почему это произошло? какой-то системный модуль зарегистировался (как у нас в linux взаимодействие с USB происходит?) в качестве обработчика чего-то там. при размонтировании его принудительно выгрузили. Регистрация осталась. Попытке обработать некий запрос от hardinfo привела к обращению к данным этого модуля. модуля в памяти не оказалось. Вполне себе возможная ситуация (почитай внимательно о том, что написано в том баге, по ссылке)
Эта ситауция принципиально не чем не отличается от выполнения кода, запущенного с флешки.

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

Это видимо ты так болезненно воспринимаешь аргументированную критику. Мне не нужно никого "поражать умными словами". Мне достаточно того, что мне платят за мои знания и опыт. Ты не смотри что у меня в профиле написано "Комсомольск-на-Амуре", я могу работать откуда угодно - удаленно на fulltime в компании с 700+ программистами, с офисами в Германии и США, занимаемся в том числе совместными разработками железа с Cisco. Я это говорю не ради "помериться", просто чтобы у тебя заблуждений не было. И уж с фундаментальной литературой в области computer science я прекрасно знаком.

Не получилось - я в ядре Linux хорошо ориентируюсь ещё с версии 0.97.

По увиденному мной уровню аргументации я в этом сомневаюсь. "ядерного" стека с отладочными символами ты судя по всему не видел...
Тебе понятно, откуда в стеке после вызова strlen появился вызов page_fault, не смотря на то, что в коде strlen он отсутствует? Это основной вопрос и он напрямую относится к обсуждаемой проблеме. То что этого нет на приведенном скриншоте ничего не меняет, этот вызов там был . Вот только не нужно приплетать сюда отладочный код.

Почитай хотя-бы так называемый "gorman book", чтоб понимать о чём речь...

О, это похоже для тебя авторитетный источник. Цитирую отсюда https://github.com/lorenzo-stoakes/linu ... aster/4.md

Pages in the process linear address space are not necessarily resident in memory.
...
Linux, like many operating system, has a Demand Fetch policy for dealing with pages that are not resident - a page is only fetched from backing storage when the hardware raises a page fault exception, which the operating system traps and allocates a page.
...
There are two types of page fault - major and minor. Major page faults occur when data has to be read from disk, which is an expensive operation. Those that do not require this are considered minor.
...

The page fault handler needs to be able to deal with the following types of page fault (written in the form severity - description - resolution):

1. Minor - Region valid but page not allocated - Allocate a page frame from the physical page allocator.
...
4. Major - Page swapped out to backing storage - Find where the page with information is stored in the PTE and read it from disk.
...
6. Error - Region is invalid or process has no permissions to access - Send a SIGSEGV signal.
...
do_page_fault() is responsible for determining which type of fault has occurred and how it should be handled by the architecture-independent code

Ликбез говоришь? Найди 10 отличий, как говорится, от того что я тебе говорил. (это кстати у тебя такой прием ведения обсуждения? игнорировать аргументы и отсылать к источниками, в которых приводятся абсолютно эти же аргументы )

Обсуждаемая ошибка свазана с тем что в процессе обработки page_fault была детектирована необходимость подкачки страницы с диска (пункт 4 в цитате выше), но непосредственно сама подкачка завершилась неудачей. Почему - это отдельный вопрос. Я ведь еще в самом начале писал что это вполне могло случиться из-за bad sector на системном диске например.

Поэтому не вижу смысла в продолжении разговора.

Как-то слабо верится...

Ну на бессмысленные разговоры меня долго не хватит. Просто не хочу чтобы ты вводил в заблужение остальных участников форума.

[Serg]

Как именно? как проиходит создание АП для процесса?

Это вообще не имеет отношения к теме, не надо "незаметно отползать" в сторону.

Попытке обработать некий запрос от hardinfo привела к обращению к данным этого модуля. модуля в памяти не оказалось.

В этом случае это самое "обращение" просто вернёт ошибку в пользовательский код (hardinfo), у ядра не будет необходимости пристреливать процесс.

аргументированную критику.

Тебе кто-то сказал, что твоя критика аргументированная, или ты сам так решил?..

Тебе понятно, откуда в стеке после вызова strlen появился вызов page_fault, не смотря на то, что в коде strlen он отсутствует? Это основной вопрос и он напрямую относится к обсуждаемой проблеме. То что этого нет на приведенном скриншоте ничего не меняет, этот вызов там был .

https://youtube.com/watch?v=EHX7NZS8zAI

Ликбез говоришь? Найди 10 отличий, как говорится, от того что я тебе говорил. (это кстати у тебя такой прием ведения обсуждения? игнорировать аргументы и отсылать к источниками, в которых приводятся абсолютно эти же аргументы )

Аналогичный приём: цитировать умные фразы, не имеющие отношения к вопросу.
Я ничего не говорил про динамическое выделение памяти процессу. Я лишь сказал, что например из объявленного массива типа
static char buff[10]
попытались прочитать больше 10 байт, т.е. процесс попытался обратиться к чужой области памяти, за что и был пристрелен ядром посредством сигнала SIGSEGV. И что информация о причинах этого возможно есть в логе за верхней границей экрана (на скриншоте).
Но тут появился netrider с умными словами про распределение памяти...

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