Как правильно отлаживать ядро линукс трассировка и т д
Обновлено: 30.06.2024
Каковы наиболее распространенные и почему не необычные методы и инструменты, используемые для активной отладки ядра Linux? Я знаю, что Линус, например. это против такого рода отладки для ядра Linux, или это было наименьшее, и поэтому в те годы в этом смысле ничего не было сделано, но, честно говоря, много времени прошло с 2000 года, и мне интересно, изменился ли этот менталитет в отношении проекта Linux и какие текущие методы используются для активной отладки в ядре Linux на данный момент (локальном или удаленном)?
Приветствуются ссылки на пошаговые руководства и руководства по указанным методам и инструментам.
Другой вариант - использовать контроллер ICE/JTAG и GDB. Это "аппаратное" решение особенно используется со встроенными системами,
но, например, Qemu предлагает аналогичные функции:
запустите qemu с удаленной заглушкой gdb, которая прослушивает localhost: 1234: qemu -s. ,
затем с помощью GDB вы открываете файл ядра vmlinux скомпилированный с отладочной информацией (вы можете посмотреть этот список рассылки, где обсуждается неоптимизация ядра).
соедините GDB и Qemu: target remote localhost:1234
увидеть ваше живое ядро:
к сожалению, пользовательская отладка темпа -s пока невозможна с GDB (нет информации о списке задач, нет перепрограммирования MMU, чтобы увидеть различные контексты процесса. ), но если вы остаетесь в темпе ядра -s, это довольно удобно.
- info threads предоставят вам список и состояния различных процессоров.
РЕДАКТИРОВАТЬ:
Вы можете получить более подробную информацию о процедуре в этом PDF:
При отладке ядра Linux мы можем использовать несколько инструментов, например, отладчиков (KDB, KGDB), демпинг при сбое (LKCD), инструментарий трассировки (LTT, LTTV, LTTng), пользовательские инструменты ядра (dprobes, kprobes). В следующем разделе я попытался обобщить большинство из них, надеюсь, что это поможет.
LKCD (инструмент для сброса ядра Linux) позволяет системе Linux записывать содержимое своей памяти при сбое. Эти журналы могут быть дополнительно проанализированы для основной причины сбоя. Ресурсы относительно LKCD
Динамические зонды - один из популярных инструментов для отладки Linux, разработанный IBM. Этот инструмент позволяет размещать "зонд" практически в любом месте в системе, как в пространстве пользователя, так и в ядре. Зонд состоит из некоторого кода (написанного на специализированном языке, ориентированном на стек), который выполняется, когда управление попадает в данную точку. Ресурсы, касающиеся динамического зонда, перечисленные ниже
Инструмент Linux Trace Toolkit - это патч ядра и набор связанных утилит, которые позволяют отслеживать события в ядре. Трассировка включает в себя информацию о времени и может создать достаточно полную картину того, что произошло за определенный период времени. Ресурсы LTT, LTT Viewer и LTT следующего поколения
MEMWATCH - инструмент обнаружения ошибок с открытым исходным кодом. Он работает, определяя MEMWATCH в инструкции gcc и добавляя заголовочный файл к нашему коду. Благодаря этому мы можем отслеживать утечки памяти и повреждение памяти. Ресурсы, касающиеся MEMWATCH
ltrace - это утилита для отладки в Linux, используемая для отображения вызовов, которые приложение пользовательского пространства делает для разделяемых библиотек. Этот инструмент можно использовать для отслеживания любого вызова динамической библиотеки. Он перехватывает и записывает вызовы динамической библиотеки, вызываемые выполненным процессом, и сигналы, полученные этим процессом. Он также может перехватывать и печатать системные вызовы, выполняемые программой.
KDB - это отладчик ядра ядра Linux. KDB следует за упрощенным интерфейсом в стиле оболочки. Мы можем использовать его для проверки памяти, регистров, списков процессов, dmesg и даже установки точек останова для остановки в определенном месте. Через KDB мы можем установить контрольные точки и выполнить некоторое базовое управление запуском ядра (хотя KDB не является отладчиком исходного уровня). Несколько полезных ресурсов в отношении KDB
KGDBпредназначен для использования в качестве отладчика исходного уровня для ядра Linux. Он используется вместе с gdb для отладки ядра Linux. Для использования kgdb требуются две машины. Одна из этих машин - машина для разработки, а другая - целевая машина. Ядро для отладки выполняется на целевой машине. Ожидается, что gdb можно использовать для "взлома" ядра для проверки памяти, переменных и просмотра информации о стеке вызовов, аналогичной тому, как разработчик приложения будет использовать gdb для отладки приложения. Можно разместить точки останова в коде ядра и выполнить некоторое ограниченное выполнение шага. Несколько полезных ресурсов в отношении KGDB
Каковы наиболее распространенные и почему не необычные методы и инструменты, используемые для отладки ядра Linux в реальном времени? Я знаю, что Линус, например. против этого вида отладки для ядра Linux, или, по крайней мере, так было и таким образом, в те годы в этом смысле ничего особенного не было сделано, но, честно говоря, с 2000 года прошло много времени, и мне интересно, изменилось ли это мышление в отношении проекта Linux и какие текущие методы используются для отладки в реальном времени в ядре Linux на данный момент (локальный или удаленный)?
Ссылки на пошаговые руководства и учебные пособия по упомянутым методам и инструментам приветствуются.
Другой вариант - использовать контроллер ICE / JTAG и GDB. Это «аппаратное» решение особенно используется со встроенными системами,
Но, например, Qemu предлагает аналогичные функции:
запустите qemu с заглушкой gdb 'remote', которая прослушивает 'localhost: 1234': qemu -s . ,
затем с помощью GDB вы открываете файл ядра vmlinux , скомпилированный с отладочной информацией (вы можете посмотреть в этой ветке списка рассылки, где обсуждается неоптимизация ядра).
соединить GDB и Qemu: target remote localhost:1234
посмотрите ваше живое ядро:
К сожалению, отладка в пространстве пользователя с GDB пока невозможна (нет информации о списке задач, нет перепрограммирования MMU для просмотра различных контекстов процессов, . ), но если вы остаетесь в пространстве ядра, это довольно удобно.
- info threads предоставит вам список и состояния различных процессоров
РЕДАКТИРОВАТЬ:
Вы можете получить более подробную информацию о процедуре в этом PDF-файле:
При отладке ядра Linux мы можем использовать несколько инструментов, например, отладчики (KDB, KGDB), дамп при сбое (LKCD), инструментарий трассировки (LTT, LTTV, LTTng), настраиваемые инструменты ядра (dprobes, kprobes). В следующем разделе я попытался обобщить большинство из них, надеюсь, это поможет.
Инструмент LKCD (Linux Kernel Crash Dump) позволяет системе Linux записывать содержимое своей памяти в случае сбоя. Эти журналы можно дополнительно проанализировать для выявления основной причины сбоя. Ресурсы, касающиеся LKCD
Динамические пробы - один из популярных инструментов отладки для Linux, разработанный IBM. Этот инструмент позволяет разместить «зонд» практически в любом месте системы, как в пространстве пользователя, так и в пространстве ядра. Зонд состоит из некоторого кода (написанного на специализированном стек-ориентированном языке), который выполняется, когда элемент управления достигает заданной точки. Ресурсы, касающиеся Dynamic Probe, перечислены ниже
Linux Trace Toolkit - это исправление ядра и набор связанных утилит, которые позволяют отслеживать события в ядро. Трассировка включает информацию о времени и может создать достаточно полную картину того, что произошло за определенный период времени. Ресурсы LTT, LTT Viewer и LTT Next Generation
MEMWATCH - это инструмент для обнаружения ошибок памяти с открытым исходным кодом. Он работает, определяя MEMWATCH в инструкции gcc и добавляя файл заголовка в наш код. Благодаря этому мы можем отслеживать утечки и повреждения памяти. Ресурсы, касающиеся MEMWATCH
ltrace - это утилита отладки в Linux, используемая для отображения вызовы, которые приложение пользовательского пространства делает к разделяемым библиотекам. Этот инструмент можно использовать для отслеживания любого вызова функции динамической библиотеки. Он перехватывает и записывает вызовы динамической библиотеки, которые вызываются исполняемым процессом, и сигналы, которые принимает этот процесс. Он также может перехватывать и печатать системные вызовы, выполняемые программой.
KDB - это отладчик ядра Linux. KDB следует упрощенному интерфейсу в стиле оболочки. Мы можем использовать его для проверки памяти, регистров, списков процессов, dmesg и даже для установки точек останова в определенном месте. С помощью KDB мы можем устанавливать точки останова и выполнять некоторые базовые функции управления запуском ядра ( Хотя KDB не является отладчиком исходного уровня ). Несколько полезных ресурсов по KDB
KGDB предназначен для использования в качестве отладчика исходного кода для ядра Linux. Он используется вместе с gdb для отладки ядра Linux. Для использования kgdb требуются две машины. Одна из этих машин является машиной для разработки, а другая - целевой машиной. Отлаживаемое ядро запускается на целевой машине. Ожидается, что gdb можно использовать для «взлома» ядра для проверки памяти, переменных и просмотра информации стека вызовов аналогично тому, как разработчик приложения использовал бы gdb для отладки приложения. Можно размещать точки останова в коде ядра и выполнять некоторые ограниченные пошаговые действия. Несколько полезных ресурсов о KGDB
Согласно wiki, kgdb был объединен с ядром в 2.6.26 за последние несколько лет. kgdb - это удаленный отладчик, поэтому вы активируете его в своем ядре, затем присоединяете gdb к это как-то. Я как-то говорю, поскольку, кажется, есть много вариантов - см. подключение gdb. Учитывая, что kgdb теперь находится в дереве исходных текстов, я бы сказал, что в дальнейшем это то, что вы хотите использовать.
Итак, похоже, что Линус сдался. Однако я бы подчеркнул его аргумент - вы должны знать, что делаете, и хорошо знать систему. Это земля ядра. Если что-то пойдет не так, вы не получите segfault , вы получите что-нибудь от какой-то неясной проблемы позже до выхода из строя всей системы. Вот драконы. Будьте осторожны, вас предупредили.
Еще один хороший инструмент для «живой» отладки - kprobes / dynamic probes.
Это позволяет вам динамически создавать маленькие крошечные модули, которые запускаются при выполнении определенных адресов - что-то вроде точки останова.
Большим их преимуществом являются:
- Они не влияют на систему - то есть при попадании в какое-либо место - они просто исключают код - это не останавливает все ядро.
- Вам не нужно соединять две разные системы (целевая и отладочная), как в случае с kgdb.
Он лучше всего подходит для таких вещей, как достижение точки останова и просмотр значений данных, или проверка того, были ли что-то изменены / перезаписаны и т. Д. Если вы хотите «пошагово выполнить код» - он этого не делает.
Еще один очень мощный метод - это программа, называемая просто "perf", которая объединяет многие инструменты (например, динамические зонды) и заменяет / обесценивает другие (например, oprofile).
В частности, команду perf probe можно использовать для простого создания / добавления динамических зондов в систему, после чего perf record может производить выборку системы и сообщать информацию (и обратные трассировки) при попадании в зонд для отчета через perf report (или perf script ). Если у вас есть хорошие символы отладки в ядре, вы можете получить отличную информацию из системы, даже не отключая ядро. Сделайте man perf (в Google или в вашей системе), чтобы получить дополнительную информацию об этом инструменте, или просмотрите эту замечательную страницу о нем:
Пошаговая инструкция по KGDB + QEMU
KGDB - это подсистема ядра, которая позволяет выполнять пошаговую отладку самого ядра с хост-GDB.
Плюсы и минусы по сравнению с другими методами:
- преимущество перед QEMU:
- у вас часто нет программной эмуляции для вашего устройства, поскольку поставщики оборудования не любят выпускать точные модели программного обеспечения для своих устройств.
- реальное оборудование намного быстрее, чем QEMU
Скомпилируйте ядро с помощью:
Большинство из них не являются обязательными, но это то, что я тестировал.
Добавьте в свою команду QEMU:
Запустите GDB из корня дерева исходных текстов ядра Linux с помощью:
и загрузка должна закончиться.
И GDB должен сломаться.
Теперь все готово, вы можете использовать GDB как обычно:
Протестировано в Ubuntu 14.04.
KGDB + Raspberry Pi
Та же самая настройка, что и выше, почти работала на Raspberry Pi 2, Raspbian Jessie 27.05.2016.
Вам просто нужно научиться выполнять шаги QEMU на Pi, которые легко доступны в Google:
отредактируйте cmdline.txt загрузочного раздела и добавьте:
подключите gdb к последовательному порту с помощью:
изнутри сеанса SSH, поскольку серийный номер уже занят GDB.
При такой настройке я смог поставить точку останова в sys_write , приостановить выполнение программы, перечислить источник и продолжить.
Поэтому я не уверен, что с моей настройкой что-то не так, или это ожидается из-за того, что какой-то фоновый процесс делает в более сложном образе Raspbian.
Мне также сказали попробовать отключить многопроцессорность с помощью параметров загрузки Linux, но я еще не пробовал.
Пошаговая процедура QEMU + GDB, протестированная на хосте Ubuntu 16.10
Сначала получите корневую файловую систему rootfs.cpio.gz . Если он вам нужен, подумайте:
Затем в ядре Linux:
На другом терминале, предположим, вы хотите начать отладку с start_kernel :
Беспорядочный disconnect и то, что следует за ним, предназначены для устранения ошибки:
На самом деле шутка заключается в том, что Linux имеет отладчик в ядре с 2.2.12, xmon , но только для архитектуры powerpc (на самом деле тогда это был ppc ).
Это не отладчик исходного уровня, и он почти полностью недокументирован, но все же.
Как человек, который много пишет код ядра, я должен сказать, что никогда не использовал kgdb и очень редко использую kprobes и т. Д.
Часто это все еще лучший способ добавить стратегическое printks . В более поздних ядрах trace_printk - хороший способ сделать это без рассылки спама в dmesg.
Вы, ребята, ошибаетесь, kgdb по-прежнему хорошо работает с последним ядром, вам нужно позаботиться о конфигурации ядра для разделенного образа, оптимизации рандомизации.
Kgdb через последовательный порт бесполезен, потому что ни один компьютер сегодня не поддерживает DB9 на последовательном порту материнской платы, а последовательный порт USB не поддерживает режим опроса.
Новая игра - kgdboe, трассировка журнала:
Ниже находится хост-машина, vmlinux - с целевой машины
На одноранговой целевой машине ниже показано, как вызвать сбой и захватить хост-машиной.
Kgdb и gdb почти бесполезны для отладки ядра, потому что код настолько оптимизирован, что не имеет никакого отношения к исходному источнику, а многие переменные оптимизированы. Это делает steppijng, следовательно, переход через источник невозможен, изучение переменных невозможно и, следовательно, почти всегда.
На самом деле это хуже, чем бесполезно, это на самом деле дает вам ложную информацию, поэтому код, на который вы смотрите, отключается от фактического работающего кода.
И нет, в ядре нельзя отключить оптимизацию, оно не компилируется.
Я должен сказать, что, исходя из среды ядра Windows, отсутствие достойного отладчика раздражает, учитывая, что существует ненужный код, который нужно поддерживать.
Пользовательский режим Linux (UML)
Еще одна виртуализация, еще один метод, позволяющий пошагово отладить код ядра.
UML очень изобретателен: он реализован как ARCH , как и x86 , но вместо использования низкоуровневых инструкций он реализует функции ARCH с помощью системных вызовов пользовательского уровня.
В результате вы можете запускать код ядра Linux как пользовательский процесс на хосте Linux!
um defconfig устанавливает CONFIG_DEBUG_INFO=y по умолчанию (да, это вопрос разработки), так что все в порядке.
На хосте в другой оболочке:
И теперь вы управляете подсчетом из GDB и можете видеть исходный код, как и ожидалось.
- полностью содержится в основном дереве ядра Linux
- более легкий, чем полная эмуляция системы QEMU
очень инвазивный, поскольку он меняет способ компиляции самого ядра.
Но API более высокого уровня за пределами специфики ARCH должны оставаться неизменными.
Оригинал: "Device Drivers, Part 10: Kernel-Space Debuggers in Linux"
Автор: Anil Kumar Pugalia
Дата публикации: September 1, 2011
Перевод: Н.Ромоданов
Дата перевода: июнь 2012 г.В этой статье, которая является частью серии статей о драйверах устройств в Linux, рассказывается об отладке в пространстве ядра Linux.
Светлана, вернувшись из больницы, отдыхала в библиотеке, читая разные книги. С тех пор, как она узнала о способе отладки с использованием ioctl , ей не терпелось узнать больше об отладке в пространстве ядра. Ей бы хотелось узнать, как и где можно запускать отладчик пространства ядра. Отладка в пространстве ядра отличается от отладки приложений в пользовательском пространстве, когда у нас в нижнем слое работает операционная система, а над ней есть оболочка или графический интерфейс для запуска отладчика (например, отладчика gdb и отладчика data display debugger - ddd ). Затем она наткнулась на интересный способ отладки в пространстве ядра с использованием отладчика kgdb , который, начиная с ядра 2.6.26, является частью ядра.
Изучаем отладку в пространстве ядра
Поскольку нам при отладке потребуется некоторый интерфейс, можно для визуализации процесса отладки воспользоваться одним из следующих двух способов:
- Добавьте отладчик в само ядро, доступное через обычную консоль. Например, в случае kdb , который не был официальным отладчиком до ядра 2.6.35, нужно было с этого адреса FTP загрузить исходный код (два набора патчей: один — зависящий от архитектуры и один — не зависящий от архитектуры), а затем пропатчить ими исходный код ядра. Но, начиная с ядра 2.6.35, большая часть возможностей отладчика уже есть в официально выпущенном исходном коде ядра. В любом случае необходимо, чтобы поддержка kdb была добавлена в исходный код ядра при его компиляции, установке и загрузке. Отладочный интерфейс kdb будет предоставлен в загрузочном экране.
- Установите в ядре минимальный отладочный сервер; клиент через определенный интерфейс (например, последовательный или Ethernet) будет подключаться к нему с удаленного хоста или из локального пользовательского пространства. Это kgdb , сервер gdb ядра, должен использоваться с gdb в качестве его клиента. Начиная с ядра 2.6.26, последовательный интерфейс этого сервера является частью официального релиза ядра. Но, если вам интересен сетевой интерфейс, вам все равно придется пропатчить ядро с использованием одного из релизов, взятых на странице проекта kgdb . В любом случае, вам потребуется включить в ядре поддержку kgdb , перекомпиировать, установить и загрузить новое ядро.
Пожалуйста, обратите внимание, что в обоих указанных выше случаях для того, чтобы в ядре выполнять отладку, необходим полный исходный код ядра, в отличие от случая сборки модулей, когда достаточно просто заголовочных файлов. Ниже рассказывается, как пользоваться отладчиком kgdb через последовательный интерфейс.
Настройка ядра Linux с kgdb
Прежде всего, чтобы можно было в ядре осуществлять отладку, в нем должен присутствовать отладчик kgdb . Чтобы этого добиться, в исходном коде ядра следует указать параметр CONFIG_KGDB=y . Кроме того, чтобы можно было получать доступ к отладчику kgdb через последовательный порт, нужно указать параметр CONFIG_KGDB_SERIAL_CONSOLE=y . Чтобы сделать использование отладчика gdb более информативным, предпочтительно указать параметр CONFIG_DEBUG_INFO с тем, чтобы в ядре можно было формировать символьные данные. Параметр CONFIG_FRAME_POINTER=y разрешает в ядре использовать указатели фреймов, что позволяет gdb более точно выполнять трассировку стека. Все эти параметры есть в пункте "Kernel hacking" ("Настройки ядра") в меню директория исходного кода (все это предпочтительнее выполнять в роли пользователя root или с помощью команды sudo ) с помощью следующей команды:
![]()
Рис.1: Конфигурирование параметров ядра для отладчика kgdb
На рис.1 эти параметры выделены:
Как только вы сохраните конфигурацию, соберите ядро (запустите команду make ), а затем выполните команду make install для того, чтобы установить его, а также добавить в конфигурационный файл GRUB запись для установленного ядра. Конфигурационным файлом GRUB может быть, в зависимости от дистрибутива, файл /boot/grub/menu.lst , файл /etc/grub.cfg или аналогичный. После того, как выполните установку, в эту новую запись нужно будет добавить загрузочные ядра kgdb-related так, как показано в выделенном тексте на рис.2.
![]()
Рис.2: Конфигурирование GRUB для kgdb
Параметр kgdboc указывается при подключении к gdb через консоль; формат параметра kgdboc= <serial_device>, <baud-rate> где:
- <serial_device> — файл последовательного устройства (порт) в системе, работающей с отлаживаемым ядром
- <baud-rate> — скорость в бодах последовательного порта
Параметр kgdbwait указывает ядру задержать загрузку до тех пор, пока клиент gdb не подсоединится к нему, этот параметр должен указываться только после параметра kgdboc .
После этого мы готовы начать. Сделайте копию образа ядра vmlinux для использования в клиентской системе gdb . Перезагрузитесь и в меню GRUB выберите новое ядро, после чего ядро будет ожидать, пока gdb не подключится через последовательный порт.
Все приведенные выше копии экранов сделаны для версии ядра 2.6.33.14. Для исходного кода ядра любого другого релиза 2.6.3x все должно работать точно также. Кроме того, копии экранов для kgdb были получены с использованием файла последовательного устройства /dev/ttyS0 , т. е. с использованием первого последовательного порта.
Настройка gdb на другой системе
Ниже приводятся требования к системе:
- Последовательные порты системы, которая отлаживается, и второй системы, на которой запускается gdb , должны быть соединены с помощью кабеля "нуль-модем" (т. е. переходного последовательного кабеля).
- Сборку образа ядра vmlinux с подключенным kgdb необходимо скопировать из системы, которая отлаживается, в рабочий директорий в системе, где будет выполняться gdb .
Чтобы подключить gdb к ожидающему ядру, запустите gdb в командной оболочке, а затем выполните следующие команды:
В приведенных выше командах vmlinux является ядром, скопированным из системы, которая отлаживается.
Отладка с использованием gdb и kgdb
Подведем итог
В настоящий момент Светлане не терпелось попробовать kgdb . Поскольку ей для этого нужно было две системы, она отправилась в лабораторию драйверов устройств Linux. Там она настроила системы и запустила gdb так, как это было описано выше.
Самыми страшными являются не синтаксические, а так называемые логические ошибки. Ваша программа может содержать хоть сотню мелких синтаксических ошибок — там не так функцию написали, там забыли указать параметр, а где-то пропустили точку с запятой. После исправления всех этих ошибок программа будет работать.
Если же ваша программа содержит логическую ошибку — например, вы выбрали неправильный алгоритм или неправильно его использовали, — то компилятор может даже не выдать предупреждения. Вроде бы ошибок нет, программа работает, но результат выдает неправильный или в какой-то момент вообще рушится. Мне запомнился один афоризм: «Программа делает то, что вы ей сказали, но не то, что вам хочется». Это и есть самое удачное, на мой взгляд, описание логической ошибки.
Если вы заметили ошибку до того, как ваша программа «увидела свет», то можете считать, что вам повезло. Одно дело, когда программа бесплатная, другое, когда вы за нее получили деньги, а заказчик недоволен. А бывает и такое, что программа может работать один, два месяца и только потом ваша логическая ошибка «всплывает» наружу. Почему это произошло? Дать однозначный ответ сложно, даже когда видишь код программы: все зависит от ее специфики.
А вот когда вы пишете программу для управления устройством или для обработки показаний внешних датчиков, подключенных к компьютеру, бывает очень сложно найти ошибку, связанную с конфликтом на аппаратном уровне. Например, пользователь установил новое устройство, которое конфликтует с вашим контроллером. Или вы написали модуль для поддержки одного контроллера, а пользователь подключил два, и оба теперь не работают.
Какие же ошибки часто совершают начинающие (и не только) программисты? Самая тривиальная — неправильное использование операций инкремента и декремента. Например, следующие выражения не эквивалентны:
В первом случае переменной x будет присвоено значение 15, а во втором — 16.
Следующей по частоте является ошибка неучтенной единицы. Например, вам нужен массив, состоящий из 10 элементов, вы его объявляете:
А затем инициализируете его с помощью цикла:
Этот фрагмент кода попытается инициализировать несуществующий элемент — а[10].
Или еще один распространенный случай: программист забывает, что нумерация элементов массива начинается с 0, и не инициализирует первый элемент массива:
Особое место в зоопарке ошибок занимают ошибки, связанные с неправильным использованием указателей. Все эти ошибки можно условно разделить на три группы, которые я сейчас кратко перечислю.
1) Неправильное использование операторов * и &. Это самая распространенная группа ошибок начинающих программистов. Вот характерный пример такой ошибки:
*s = (char *s)malloc(25);
s = (char *s)malloc(25);
2) Выделение недостаточного для адресации объекта объема памяти. Например, мы получим такую ошибку, если попытаемся скопировать в строку s (вышеприведенный фрагмент кода) строку, состоящую из 30 символов,
3) Использование неинициализированных указателей. Такие ошибки часто встречаются при работе с динамическими структурами. Например, с линейными списками: вы забыли инициализировать главный элемент (head = NULL) и пытаетесь добавить в список новый элемент.
Использование рекурсивных вызовов может повлечь за собой ошибку переполнения стека, если вы неправильно зададите условие завершения рекурсии. Как правило, рекурсивная функция вызывает саму себя с несколько измененными параметрами. Рано или поздно такая функция должна, в зависимости от переданных параметров, возвратить какое-нибудь значение, а не опять вызвать саму себя.
Для облегчения поиска ошибок были созданы специальные программы — отладчики. Одним из самых удачных отладчиков для Linux является gdb (The GNU Debugger). Этот отладчик входит в состав всех распространенных дистрибутивов (за исключением их «урезанных» версий — для рабочих станций), и для его установки достаточно установить пакет gdb.
С помощью gdb вы сможете:
? запустить вашу программу с определенными аргументами;
? запустить программу в пошаговом режиме;
? установить точки останова (breakpoint);
? установить условие останова программы;
? узнать, что случилось, если программа неожиданно завершилась.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Глава 15 Отладка
Глава 15 Отладка Имеется множество правил, начиная с логики программы и расположения данных, через организацию и расположение кода и кончая реализацией, которые могут минимизировать ошибки и проблемы. Мы рекомендуем вам изучить их; найдите хорошие книги по
Глава 18 Отладка
Глава 18 Отладка Один из самых существенных факторов, который отличает разработку ядра от разработки пользовательских приложений, — это сложность отладки. Отлаживать код ядра сложно, но крайней мере по сравнению с кодом пространства пользователя. Еще больше усугубляет
Глава 6. CSS оптимизация
Глава 6. CSS оптимизация 6.1. Оптимизируем CSS expressions CSS-производительность не находится сейчас в фокусе внимания при разработке клиентских приложений для браузера. Очень часто о некоторых ключевых моментах просто не знают (или забывают), и это может привести к появлению
Глава 7. Оптимизация JavaScript
Глава 7. Оптимизация JavaScript 7.1. Кроссбраузерный window.onload Отложенная загрузка скриптов волнует общественность уже давно, почти 10 лет, — атрибут defer, призванный ее обеспечить, был добавлен в спецификацию еще в прошлом столетии. Однако проблема так и остается
22.5. Оптимизация программ. Профайлер gprof
22.5. Оптимизация программ. Профайлер gprof Ваша программа работает медленно? Скорее всего, причина кроется в неэффективном, медленном алгоритме. Существуют программы, позволяющие определить время работы каждой функции вашей программы и всей программы в целом. Программы
Глава 7 Оптимизация Windows
Глава 7 Оптимизация Windows В данной главе речь пойдет о параметрах реестра, с помощью которых можно повысить скорость или качество работы различных компонентов Windows XP, например таких, как сетевое соединение и стеки протоколов, а также скорость самой операционной системы.
Глава 5 Оптимизация
Глава 5 Оптимизация …ты скажи ему, что во всякой вещи надо соблюдать меру… Уильям Шекспир. Много шума из ничего «Любая задача выполнима, если она поддается измерению». Давайте поверим в данное утверждение и постараемся правильно выбрать показатели, которые будем
ГЛАВА 8. ОТЛАДКА ПРОЛОГ-ПРОГРАММ
ГЛАВА 8. ОТЛАДКА ПРОЛОГ-ПРОГРАММ На приведенных выше примерах вы уже приобрели опыт применения программ и научились их изменять, а также успели написать и свои собственные программы. Теперь самое время заняться вопросом: что делать, когда программа ведет себя не так, как
Глава 9. "Бронированный" программный код: отладка и устранение ошибок.
Глава 9. "Бронированный" программный код: отладка и устранение ошибок. В этой главе .
Каталог всевозможных ошибок, стремящихся "одурачить" вашу программу
Принципы борьбы с ошибками
Замечательная возможность - режим паузы
Все средства отладки редактора Visual Basic, включая
Глава 16. Тестирование и отладка
Глава 16. Тестирование и отладка Неполадки в блоке АЕ-35. В ближайшие семьдесят два часа блок может отказать. Артур Кларк, «Космическая Одиссея 2001 года» Тестирование — вещь важная. Все компетентные программисты об этом знают, хотя не всегда этот вопрос стоит для них на
2. Отладка и трассировка.
Глава 6 Оптимизация
Глава 6 Оптимизация Если с увеличением объема вашей базы данных она стала работать слишком медленно, зачастую самый простой путь решения этой проблемы – увеличение мощности аппаратной платформы сервера. Однако повысить быстродействие системы можно и без наращивания
Глава 29. Отладка сценариев
Читайте также:
