Как отладить программу без отладчика? [закрытый]

Всего пара предложений:

1) Утверждения. Это должно помочь вам выработать общие ожидания на разных этапах программы. Также ознакомьтесь с кодом

2) Модульные тесты. Я использовал их время от времени, чтобы копаться в новом коде и тестировать API

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

Кандидат: Значит, вы не покупаете отладчики для своих разработчиков?
Опрашивающий: Нет, у них есть отладчики.

Кандидат : Значит, вы ищете программистов, которые из мазохизма или хамартии усложняют себе жизнь, даже если они будут менее продуктивными?
Интервьюер: Нет, я просто пытаюсь понять, знаете ли вы, что бы вы сделали в ситуации, которой никогда не случится.

Кандидат: Я бы добавил операторы протоколирования или печати. Могу я задать вам аналогичный вопрос?
Интервьюер: Конечно.

Кандидат: Как бы вы набрали команду разработчиков, если бы вы этого не сделали?

Одно слово: ведение журнала.

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

Java: log4j

.Net: NLog или log4net

Python: Python Logging

PHP: Pear Logging Framework

Ruby: Ruby Logger

C: log4c

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

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

Двоичный поиск по времени также является методом: если у вас есть исходный код, хранящийся в репозитории управления версиями, и вы знаете, что версия 100 работает, а версия 200 - нет, попробуйте посмотрим, работает ли версия 150. Если это так, ошибка должна быть между версией 150 и 200, поэтому найдите версию 175 и посмотрите, работает ли она ... и т. Д.

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

В системах * nix strace и / или dtrace могут очень много рассказать о выполнении вашей программы и используемых библиотеках.

• используйте println / log in код
• использовать проводник БД для просмотра данных в DB / файлах
• писать тесты и помещать утверждения в подозрительные места

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

Оператор Print не всегда подходит. Вы можете использовать другие формы вывода, такие как запись в журнал событий или файл журнала, запись в сокет TCP (у меня есть хорошая утилита, которая может прослушивать этот тип трассировки из моей программы) и т. Д.

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

Существование другого файла может вызвать запись внутреннего состояния программы в ваш механизм регистрации.

Spy ++ (а в последнее время Snoop для WPF) очень полезны для понимания ошибок пользовательского интерфейса Windows.

как и все остальные сказали:

• Журнал
• Утверждает
• Дополнительный вывод

и

ваш любимый диспетчер задач или процесс Explorer

связывает здесь и здесь

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

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

Вы можете получить настоящую фантазию и даже настроить поток, который слушает последовательный терминал и отвечает на команды. Я также сделал это и реализовал простые команды для создания дампа списка, просмотра внутренних переменных и т. Д., И все это через простой последовательный порт RS-232 со скоростью 9600 бод!

First of all, what does debugging actually do? Advanced debuggers give you machine hooks to suspend execution, examine variables and potentially modify state of a running program. Most programs don't need all that to debug them. There are many approaches:

1. Tracing: implement some kind of logging mechanism, or use an existing one such as dtrace(). It usually worth it to implement some kind of printf-like function that can output generally formatted output into a system log. Then just throw state from key points in your program to this log. Believe it or not, in complex programs, this can be more useful than raw debugging with a real debugger. Logs help you know how you got into trouble, while a debugger that traps on a crash assumes you can reverse engineer how you got there from whatever state you are already in. For applications that you use other complex libraries that you don't own that crash in the middle of them, logs are often far more useful. But it requires a certain amount of discipline in writing your log messages.

2. Program/Library self-awareness: To solve very specific crash events, I often have implemented wrappers on system libraries such as malloc/free/realloc which extensions that can do things like walk memory, detect double frees, attempts to free non-allocated pointers, check for obvious buffer over-runs etc. Often you can do this sort of thing for your important internal data types as well -- typically you can make self-integrity checks for things like linked lists (they can't loop, and they can't point into la-la land.) Even for things like OS synchronization objects, often you only need to know which thread, or what file and line number (capturable by __FILE__, __LINE__) the last user of the synch object was to help you work out a race condition.

3. If you are insane like me, you could, in fact, implement your own mini-debugger inside of your own program. This is really only an option in a self-reflective programming language, or in languages like C with certain OS-hooks. When compiling C/C++ in Windows/DOS you can implement a "crash-hook" callback which is executed when any program fault is triggered. When you compile your program you can build a .map file to figure out what the relative addresses of all your public functions (so you can work out the loader initial offset by subtracting the address of main() from the address given in your .map file). So when a crash happens (even pressing ^C during a run, for example, so you can find your infinite loops) you can take the stack pointer and scan it for offsets within return addresses. You can usually look at your registers, and implement a simple console to let you examine all this. And voila, you have half of a real debugger implemented. Keep this going and you can reproduce the VxWorks' console debugging mechanism.

4. Another approach, is logical deduction. This is related to #1. Basically any crash or anomalous behavior in a program occurs when it stops behaving as expected. You need to have some feed back method of knowing when the program is behaving normally then abnormally. Your goal then is to find the exact conditions upon which your program goes from behaving correctly to incorrectly. With printf()/logs, or other feedback (such as enabling a device in an embedded system -- the PC has a speaker, but some motherboards also have a digital display for BIOS stage reporting; embedded systems will often have a COM port that you can use) you can deduce at least binary states of good and bad behavior with respect to the run state of your program through the instrumentation of your program.

5. A related method is logical deduction with respect to code versions. Often a program was working perfectly at one state, but some later version is not longer working. If you use good source control, and you enforce a "top of tree must always be working" philosophy amongst your programming team, then you can use a binary search to find the exact version of the code at which the failure occurs. You can use diffs then to deduce what code change exposes the error. If the diff is too large, then you have the task of trying to redo that code change in smaller steps where you can apply binary searching more effectively.

Было бы неплохо прочитать Delta Debugging от Андреаса Зеллера. Это похоже на двоичный поиск для отладки