Заменить PAGE FAULT

Internal structure and you change requests/suggestions
  • Может я тоже чего-то не понимаю, но PAGE FAULT, как и многие другие подобные ошибки, говорит о том, что неизвестно, каким образом должно происходить дальнейшее выполнение программы. Как же можно дать ей выполняться дальше, если непонятно, что можно сделать, чтобы это стало возможным?
    Насчёт подробрости и дружелюбности выводимого (в текущей реализации) на доску отладки сообщения, мне его обычно хватает, чтобы понять, где именно произошла ошибка (значения EIP и CS), а зачастую и почему именно (значения остальных регистров). Расскажи, почему этих данных тебе не хватает и что бы ты к ним добавил, чтобы сделать свою жизнь легче.
    in code we trust
  • Доска отладки меня не устраивает своей ограниченностью. На нее пишут многие программы и никакой фильтрации по логам кроме ядерные/прикладные. К тому же она медленно работает и возможность того, что новые данные затрут предыдущие никто не отменял.

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

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

    З.Ы. Твое толкование PAGE FAULT несколько отличается от вкипедии http://en.wikipedia.org/wiki/Page_fault
  • PAGE FAULT, в моём понимании (ссылку ещё не смотрел), есть ошибка обращения к памяти по адресу, не принадлежащему адресному пространству данного процесса. Мои же рассуждения выше связаны с описанием общей природы исключительных ситуаций.

    Допустим, что произошло обращение к памяти по некорректному адресу. Что может в этом случае сделать ядро, чтобы выйти из ситуации, не убив процесс? Максимум - сделать этот блок памяти доступным для процесса, потому что оно понятия не имеет, зачем он вообще туда полез. Сказано - сделано. Что происходит дальше? Дальше программа продолжает работать, но так как она прочитала (или записала) по невесть какому адресу данные, она и знать не знает, что эти данные могут быть невалидными (мы-то знаем, нас ядро предупредило). В конце-концов, слово за слово, программа таки понимает, что ей подсунули фуфло (или же она безвозвратно потеряла данные, которые записала невесть куда), возможно даже через полчаса работы с фэйковым массивом информации, и с гордостью нам об этом сообщает. Все довольны, только смысла в этом никакого нет, так как и без того ясно, по первому уведомлению от ядра, что программа делает что-то не то и смысла продолжать нет, потому что ошибки нужно исправлять по мере их поступления, а не с последней к первой.

    И вот я опять прихожу к вопросу о том, чего тебе не хватает и что именно ты предлагаешь поменять в поведении ядра? :)
    in code we trust
  • Даже не так, извини. Понятно, что ты хочешь поменять, но непонятно, как это поможет. ИМХО, только ещё больше запутает, потому что наиболее важная информация - в первом сообщении, а все остальные могут прямо или косвенно зависеть от него.
    in code we trust
  • mike.dld wrote:но непонятно, как это поможет.
    Mario wrote: и никакой фильтрации по логам
  • Элита
    Не нужно связывать несвязуемое. Обработка PAGE FAULT и фильтрация логов далеки друг от друга. Но я согласен, отсутствие последнего доставляет некоторые неудобства, хотя с таким же успехом можно обвинить ядро в маленьком размере буфера или программу DEBUG в маленьком размере окна (файл BOARD.LOG умышленно не упоминаю).
    in code we trust
  • впихнул не впихуемое. Молчу
  • Вообще-то в ядре уже имеется довольно неслабая обработка #PF.
    Там, где можно достоверно определить источник ошибки - он определяется и делает полезное дело.
    Например, #PF разруливает "ленивое" выделение страниц памяти приложению, и однозначно определяет попытки обращения к "ядерным" страницам.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • Ленивое выделение страниц - это полезное и вполне логичное применение #PF, но насколько я понимаю, Марат говорит о ситуациях, когда ядро всё-таки не может определить причину обращения к странице. Иначе оно бы не прибивало соответствующий процесс.
    in code we trust
  • Сначала мне показалось что речь о возможности приложения повесить обработчик на "Segmentation fault", что было бы полезным (а заодно и на "Division by zero" и пр.) как это сделано для исключений в FPU. но похоже ошибся.
    Я не считаю что страница (если я правильно понял) должна выделяться и продолжаться выполнение программы как будто ничего не произошло, а что если на эту страницу EIP попал? Вероятно мы получим полную порчу данных и стэка (более менее целых на момент ошибки) и выделение этому приложению всей памяти (множественные ошибки PF/segfault).
    Свой обработчик универсальнее, он в том числе мог бы таки выделить страницу и вернуть управление, или вызвать внешний отладчик, или свой встроенный использовать.

    ..bw
  • Можно и свой обработчик, главное чтобы программа не просто тупо валилась.
  • В таком случае, неплохим вариантом может быть запуск отладчика и присоединение его к процессу, создавшему исключительную ситуацию. Мне бы хватило. А писать свой обработчик #PF в userland я бы ни за что не стал. Тем более, что он по идее должен быть отдельным процессом (коим отладчик уже и так является), так как исполнять код в контексте процесса, находящегося в теоретически неконсистентном состоянии, - себе дороже.
    in code we trust
  • > А писать свой обработчик #PF в userland я бы ни за что не стал.
    А почему во "взрослых" системах пишут? Т.е. есть возможность.
    > себе дороже
    Ну те же исключения FPU можно обрабатывать, хотя это тоже процесс накосячил и непонятно как обработчик заработает.
    Обработчик конечно же не должен спасать процесс, а вывести исчерпывающую отладочную информацию, например traceback/callback с именами функций и чем чёрт не шутит со значениями локальных переменных; врядли можно написать стороннюю софтину на все случаи жизни, ведь в разных компиляторах и разных языках это может достигаться разными способами, не говоря о более специализированной инфе (буфер какой-нибудь сетевой).

    ..bw
  • 68.24
    Сделаем мир лучше!
  • Who is online

    Users browsing this forum: No registered users and 4 guests