Использование отладчика для поиска багов и отладки LCNC

[torvn77]

Как искать баги в LinuxCNC?
Как правильно собирать информацию о состоянии программы и оформлять её в багрепост?
Ясно что для того чтобы начать отладку надо поставить пакеты с dev в имени,
Но вот что делать дальше,какой использовать отладчик и как запускать программу?
Я новичёк в программировании и ничего не знаю.
Цель научится писать более полные багрепосты.

[Serg]

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

В Linux (и большинстве других Unix) отладчик один - GDB (не смотря на обилие разнообразных интерфейсов к нему). Он может потребоваться если программа падает с сообщением типа "Segmentation failed". В простейшем случае достаточно такой инструкции:
1. Скомпилить программу с оцией компилятора и линкера -g.
2. Разрешить системе создавать файл с образом памяти упавшей программы (файл core).
3. Заустить прогу и выполнить действия приводящие к падению.
4. Запустить gdb, указав ему бинарный файл программы и файл core.
5. Внутри gdb выполнить команду backtrace - если все компоненты собраны с -g, то gdb покажет команду, приводящую к падению с точностью до конкретной функции и строки исходника.
6. Тот, кто понимает, что ему написали и знает язык в достаточной мере может попробовать сам выяснить причину падения и исправить ошибку, все остальные просто прикладывают вывод команды backtrace к багрепорту.

Код: Выделить всё

$ cat tst.c
void main(void)
{
	char *s = "hello, world";
	*s = 'H';
}
$ make tst
cc     tst.c   -o tst
$ ./tst
Ошибка сегментирования (core dumped)
$ ls
tst  tst.c
$ rm tst
$ ulimit -c 1000000
$ CFLAGS=-g make tst
cc -g    tst.c   -o tst
$ ./tst
Ошибка сегментирования (core dumped)
$ ls
core.13476  tst  tst.c
$
$ gdb ./tst core.13476
GNU gdb (GDB) Fedora 7.7.1-15.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tst...done.
[New LWP 13476]
Core was generated by `./tst'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000400500 in main () at tst.c:4
4		*s = 'H';
Missing separate debuginfos, use: debuginfo-install glibc-2.18-12.fc20.x86_64
(gdb) 
(gdb) 
(gdb) bt
#0  0x0000000000400500 in main () at tst.c:4
(gdb) quit
$ 

пояснения к командам, использованным в этом примере смотрите в соотв. мануалах.

[mhael]

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

[torvn77]

В теме для сбора багов я сделал багрепорт,проблема в том,
что сам баг непойми что,почему и как получается получается.
Сейчас у меня попросили видеоролик,не знаю будет с него толк или нет.

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

[Serg]

А можно без самостоятельной компеляции?

Даже нужно! Просто сделай то, что я в первых двух строчках написал.

То, что написал про gdb не очень-то и нужно - это пришлось написать, чтоб хоть как-то соответствовать этой теме.

[Nick]

LinuxCNC у тебя не падал такой багрепорт нам ничего не скажет.

Основная задача - найти как проявляется баг, для этого:
1. сначала пытаешься повторить все свои действия перед появлением оного.
2. находишь стабильный "путь" до появления бага
3. упрощаешь этот путь, выкидывая поочередно какие-то шаги.

В итоге получаем не шибко сложную процедуру при выполнении которой получаем баг. Если процедура не слишком сложная, ее попробуют другие пользователи и "подтвердят" баг. После этого появляется шанс, что этим багом займутся разработчики.

Да, есть хорошая вероятность, что во время прохождения всего вышеперечисленного найдется другая причина возникновения нештатной ситуации (не баг LinuxCNC, а баг в пользовательском Gкоде). Или окажется, что это не баг а фича.


ЗЫ UAVpilot спасибо за подробное описание, с примером!

[torvn77]

Компиляция...
Ладно,когда нибудь потом.

А как делать дампы в произвольный,т.е. нужный момент времени?

Nick,дело в том,что я уверен в том,что всё там описанное происходит из-за какого нибудь "переполнения буффера с выходом за пределы" и п.р. досаждающих админам и безопасникам вещей.

[Serg]

Nick,дело в том,что я уверен в том,что всё там описанное происходит из-за какого нибудь "переполнения буффера с выходом за пределы" и п.р. досаждающих админам и безопасникам вещей.

Если система при этом не завершает програму с сообщением типа "Segmentation fault", то ты не прав.

А как делать дампы в произвольный,т.е. нужный момент времени?

А нафик?..

Код: Выделить всё

$ /bin/sleep 300 &
[1] 14338
$ ps
  PID TTY          TIME CMD
 5471 pts/1    00:00:00 bash
14338 pts/1    00:00:00 sleep
14342 pts/1    00:00:00 ps
$ kill -SIGSEGV 14338
$ ps
[1]+  Ошибка сегментирования                   (core dumped) /bin/sleep 300
$ 

[torvn77]

Ну это понятно,а не убивая или калеча запущенную программу?


Вообще дело иногда заканчивается паникой ядра.

[Serg]

Запустить с gdb - с его помощью можно лазить по всем потрохам программы.

Вообще дело иногда заканчивается паникой ядра.

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

[torvn77]

Ладно,дальше я покопаюсь сам.
Потом приду задавать вопросы снова.