Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Jul 05, 2020 11:14 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 24 posts ]  Go to page 1 2 Next
Author Message
PostPosted: Thu Jan 12, 2012 8:25 pm 
Как и многие разработчики я пользуюсь отладчиком приложений. Однако я лентяй (и я думаю нас таких лентяев много) и делать дополнительные телодвижения с отладчиком мое ленивое величество предпочитает в крайнем случае - ибо долго и муторно. Чаще всего отладка идет в моем собственном мыслительном аппарате, т.е. "думай как кот код" - эмулируем исполнение собственного кода в собственной же голове, посредством мозга.

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

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

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

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


Top
   
PostPosted: Thu Jan 12, 2012 8:36 pm 
Offline
Site Founder
User avatar

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

_________________
in code we trust


Top
   
PostPosted: Thu Jan 12, 2012 9:32 pm 
Доска отладки меня не устраивает своей ограниченностью. На нее пишут многие программы и никакой фильтрации по логам кроме ядерные/прикладные. К тому же она медленно работает и возможность того, что новые данные затрут предыдущие никто не отменял.

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

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

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


Top
   
PostPosted: Thu Jan 12, 2012 10:00 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
PAGE FAULT, в моём понимании (ссылку ещё не смотрел), есть ошибка обращения к памяти по адресу, не принадлежащему адресному пространству данного процесса. Мои же рассуждения выше связаны с описанием общей природы исключительных ситуаций.

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

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

_________________
in code we trust


Top
   
PostPosted: Thu Jan 12, 2012 10:05 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
Даже не так, извини. Понятно, что ты хочешь поменять, но непонятно, как это поможет. ИМХО, только ещё больше запутает, потому что наиболее важная информация - в первом сообщении, а все остальные могут прямо или косвенно зависеть от него.

_________________
in code we trust


Top
   
PostPosted: Thu Jan 12, 2012 10:09 pm 
Offline

Joined: Sat Jun 04, 2011 4:49 pm
Posts: 93
mike.dld wrote:
но непонятно, как это поможет.


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


Top
   
PostPosted: Thu Jan 12, 2012 10:15 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
Элита
Не нужно связывать несвязуемое. Обработка PAGE FAULT и фильтрация логов далеки друг от друга. Но я согласен, отсутствие последнего доставляет некоторые неудобства, хотя с таким же успехом можно обвинить ядро в маленьком размере буфера или программу DEBUG в маленьком размере окна (файл BOARD.LOG умышленно не упоминаю).

_________________
in code we trust


Top
   
PostPosted: Thu Jan 12, 2012 11:03 pm 
Offline

Joined: Sat Jun 04, 2011 4:49 pm
Posts: 93
впихнул не впихуемое. Молчу


Top
   
PostPosted: Fri Jan 13, 2012 2:32 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1407
Вообще-то в ядре уже имеется довольно неслабая обработка #PF.
Там, где можно достоверно определить источник ошибки - он определяется и делает полезное дело.
Например, #PF разруливает "ленивое" выделение страниц памяти приложению, и однозначно определяет попытки обращения к "ядерным" страницам.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
PostPosted: Fri Jan 13, 2012 5:28 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
Ленивое выделение страниц - это полезное и вполне логичное применение #PF, но насколько я понимаю, Марат говорит о ситуациях, когда ядро всё-таки не может определить причину обращения к странице. Иначе оно бы не прибивало соответствующий процесс.

_________________
in code we trust


Top
   
PostPosted: Fri Jan 13, 2012 6:52 am 
Offline
User avatar

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

..bw


Top
   
PostPosted: Fri Jan 13, 2012 9:56 am 
Можно и свой обработчик, главное чтобы программа не просто тупо валилась.


Top
   
PostPosted: Fri Jan 13, 2012 11:20 am 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
В таком случае, неплохим вариантом может быть запуск отладчика и присоединение его к процессу, создавшему исключительную ситуацию. Мне бы хватило. А писать свой обработчик #PF в userland я бы ни за что не стал. Тем более, что он по идее должен быть отдельным процессом (коим отладчик уже и так является), так как исполнять код в контексте процесса, находящегося в теоретически неконсистентном состоянии, - себе дороже.

_________________
in code we trust


Top
   
PostPosted: Fri Jan 13, 2012 1:27 pm 
Offline
User avatar

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

..bw


Top
   
PostPosted: Fri Jan 13, 2012 2:01 pm 
Offline
Kernel Developer
User avatar

Joined: Thu Sep 03, 2009 1:52 pm
Posts: 1624
68.24

_________________
Сделаем мир лучше!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 24 posts ]  Go to page 1 2 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited