Board.KolibriOS.org

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

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

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

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

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

Может я тоже чего-то не понимаю, но PAGE FAULT, как и многие другие подобные ошибки, говорит о том, что неизвестно, каким образом должно происходить дальнейшее выполнение программы. Как же можно дать ей выполняться дальше, если непонятно, что можно сделать, чтобы это стало возможным?
Насчёт подробрости и дружелюбности выводимого (в текущей реализации) на доску отладки сообщения, мне его обычно хватает, чтобы понять, где именно произошла ошибка (значения EIP и CS), а зачастую и почему именно (значения остальных регистров). Расскажи, почему этих данных тебе не хватает и что бы ты к ним добавил, чтобы сделать свою жизнь легче.

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

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

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

З.Ы. Твое толкование PAGE FAULT несколько отличается от вкипедии http://en.wikipedia.org/wiki/Page_fault

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

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

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

Даже не так, извини. Понятно, что ты хочешь поменять, но непонятно, как это поможет. ИМХО, только ещё больше запутает, потому что наиболее важная информация - в первом сообщении, а все остальные могут прямо или косвенно зависеть от него.

mike.dld wrote:но непонятно, как это поможет.

Mario wrote: и никакой фильтрации по логам

Элита
Не нужно связывать несвязуемое. Обработка PAGE FAULT и фильтрация логов далеки друг от друга. Но я согласен, отсутствие последнего доставляет некоторые неудобства, хотя с таким же успехом можно обвинить ядро в маленьком размере буфера или программу DEBUG в маленьком размере окна (файл BOARD.LOG умышленно не упоминаю).

впихнул не впихуемое. Молчу

Вообще-то в ядре уже имеется довольно неслабая обработка #PF.
Там, где можно достоверно определить источник ошибки - он определяется и делает полезное дело.
Например, #PF разруливает "ленивое" выделение страниц памяти приложению, и однозначно определяет попытки обращения к "ядерным" страницам.

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

Сначала мне показалось что речь о возможности приложения повесить обработчик на "Segmentation fault", что было бы полезным (а заодно и на "Division by zero" и пр.) как это сделано для исключений в FPU. но похоже ошибся.
Я не считаю что страница (если я правильно понял) должна выделяться и продолжаться выполнение программы как будто ничего не произошло, а что если на эту страницу EIP попал? Вероятно мы получим полную порчу данных и стэка (более менее целых на момент ошибки) и выделение этому приложению всей памяти (множественные ошибки PF/segfault).
Свой обработчик универсальнее, он в том числе мог бы таки выделить страницу и вернуть управление, или вызвать внешний отладчик, или свой встроенный использовать.

..bw

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

В таком случае, неплохим вариантом может быть запуск отладчика и присоединение его к процессу, создавшему исключительную ситуацию. Мне бы хватило. А писать свой обработчик #PF в userland я бы ни за что не стал. Тем более, что он по идее должен быть отдельным процессом (коим отладчик уже и так является), так как исполнять код в контексте процесса, находящегося в теоретически неконсистентном состоянии, - себе дороже.

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

..bw

68.24