HLFX.Ru Forum - вопрос программистам, кодерам: как вы ищите ошибки?

Показать все 49 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Технические вопросы (https://hlfx.ru/forum/forumdisplay.php?forumid=20)
-- вопрос программистам, кодерам: как вы ищите ошибки? (https://hlfx.ru/forum/showthread.php?threadid=3676)

Отправлено thambs 09-11-2012 в 17:52:

вопрос программистам, кодерам: как вы ищите ошибки?

если не лезть в высокую науку, можно условно разделить алгоритмы на <<арифметику>> (там где что то считаем) и <<бухгалтерию>> (там где как то реорганизуем данные). и, если в арифметике найти ошибку легко, то в бухгалтерии это сущий ад. особенно, если ошибка мелкая и пакостная. например, сегодня провозился 4 часа (SIC!) в поисках ошибки в банальнейшем коде, дефрагментирущем массив на каждой итерации счёта. дошёл до того, что просто выписал злосчастный кусок его на бумагу и вручную прошёлся по каждой ветке, пока не наткнулся на то, что ... в одном месте банально перепутаны местами операторы. если уж делаю такие ошибки, то дебилу ясно, что у меня какой то косяк со стилем программирования. как таких вещей избегать?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 09-11-2012 в 18:30:

Цитата:

thambs писал:
дошёл до того, что просто выписал злосчастный кусок его на бумагу и вручную прошёлся по каждой ветке, пока не наткнулся на то, что ...

А бывает, да.

Цитата:

thambs писал:
как таких вещей избегать?

Качать "Внимательность" в Гильдии Героев.
А если серьёзно - то никак. Или просить шефа/коллег делать Code Review.

__________________

Отправлено qpAHToMAS 09-11-2012 в 18:36:

Есть еще такой вариант :

Отправлено marikcool 10-11-2012 в 06:26:

асерты через строчку влепи.

__________________
vk.com/skullcapstudios

Отправлено KiQ 10-11-2012 в 07:41:

В NetBeans есть хорошая вещь (в яве) как окно выполнения, там в реальном времени возникнет тип ошибки и строка, на которой она возникла. Если код не обфусцирован, разумеется. Ну а потом уже логика и интуиция.

__________________
-Brain is dead-

Отправлено thambs 10-11-2012 в 07:56:

KiQ

ну такие вещи я через gdb отлавливаю, а когда код 10000 раз отрабатывает правильно, а на 10001 записывает неверное значение и заметить это получается только из за нефизичного результата счёта.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 10-11-2012 в 08:45:

Цитата:

KiQ писал:
В NetBeans есть хорошая вещь (в яве) как окно выполнения, там в реальном времени возникнет тип ошибки и строка, на которой она возникла.

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

Добавлено 10-11-2012 в 15:45:

Цитата:

thambs писал:
ну такие вещи я через gdb отлавливаю

А что ты делаешь, когда гдб выдаёт ошибку в неизвестной функции, а бектрейс показывает только "??" и сомнительные адреса?

__________________

Отправлено KiQ 10-11-2012 в 09:16:

XaeroX ну это же совсем не одно и тоже. Тем более, что я работал только с VBA в ворде, лет в 13. И мне он не понравился.

__________________
-Brain is dead-

Отправлено Дядя Миша 10-11-2012 в 14:47:

Ошыбки бывают трёх типов: понятные, непонятные и порчя памяти.
Понятные ошибки, это когда тебе отладчик заботливо указывает на строчку, в которой произошел вылет. Непонятные, это когда отладчик не в силах ничего показать, только вопросики, а адрес, по которому произошел вылет обычно имеет каноничный вид 0x00000005.
Ну это понятное дело - где-то претоилса непроинициализированный указатель на функцию, переход по нему всегда даёт 4 байта от нулевого указателя, ну а дальше попытка чтения аргументов всегда заканчивается нехорошо. Отсюда и такой адрес. Найти такое достаточно легко, если вылет произошел сразу после последней модификации исходников и достаточно непросто, если к вылету привела целая цепочка случайных последовательностей. Обычные (по крайней мере для меня), методы выявления подобной пакости - это ассерты, брык-поинты и контрольные мессаги. Ну камрад Ксерокс еще наверняка упомянет _asm int 3;
основная задача - расставлять хитрые условия и проверки, постепенно сужая круг поисков. Обычное виндовое приложение работает в цикле.
Значит от начала и до конца цикла мы постепенно проходим с нашими инструментами локализуя, сначало грубо, а потом и более точно место вылета. Поскольку подобный подход чем-то напоминает бинарный алгоритм поиска, то и скорость нахождения бага обычно очень высока - не более 10 минут. В наиболее тяжелых случаях - 2-3 часа.
Порчя памяти, особенно нерегулярная есть самый настоящий ужос для разработчика, поскольку бывают случаи когда выявить истинную причину практически невозможно. Подлость тут кроется еще и в том, что приложение может нормально запускаться и работать, а падать при высвобождении памяти. Такое ни в коем случае нельзя оставлять "как есть" - кто знает как поведет себя подобная программа при длительной работе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-11-2012 в 15:06:

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

Добавлено 10-11-2012 в 22:06:

Цитата:

Дядя Миша писал:
Ну камрад Ксерокс еще наверняка упомянет _asm int 3;

В волатиле правильно писать - __asm__ __volatile__( "int 3h"), ну по понятным причинам.

__________________

Отправлено Дядя Миша 10-11-2012 в 15:44:

Цитата:

XaeroX писал:
Надо ещё очень хорошо притереться к своему компилятору

Ну вот, собственно и еще один ответ, почему я не хочу расставаться с шестой студией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-11-2012 в 16:02:

Дядя Миша
Захочешь писать кроссплатформенный код - придётся, ибо студия она только под винду.

__________________

Отправлено thambs 04-02-2013 в 16:29:

ну ёлки-палки. ну я, видимо, действительно идиот с дефектом мозга. сегодня 5(!) битых часов искал ошибку. оказалось, в одном месте, слегка не хватает точности. +нашёл одну старую ошибку, в одном месте в имени переменной было лишнее подчёркивание.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 04-02-2013 в 16:30:

Цитата:

thambs писал:
оказалось, в одном месте, слегка не хватает точности.

Осторожнее с опцией -ffast-math, я из-за неё вчера вот тоже пару часов убил на поиск ошибки "на ровном месте".

__________________

Отправлено thambs 04-02-2013 в 16:37:

XaeroX

да я так и не понял отчего так. никаких оптимизаций не использовал.
используется одна и та же функция для проверки пересечения траектории частицы с границей. так вот, если трейсить коротким вектором -- \vec{r0}->\vec{r1}, (начальное положение частицы->конечное положение частицы), то этот \vec{r1} изредка почти лежит на границе и пересечение не детектируется, а если трейсить длинным вектором, из того же \vec{r1} до какой ни будь точки вне системы и по кол-ву пересечений определять вылетела частица или нет, то всё прекрасно отрабатывает. или я идиот или одно из двух. сделаю двойную проверку тогда, что б уж наверняка.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 04-02-2013 в 16:41:

Цитата:

thambs писал:
то этот r1 изредка почти лежит на границе и пересечение не детектируется

Либо где-то стоит ">" вместо ">=", либо снижена точность математики.
Ты во флоатах или в даблах считаешь?
_controlfp юзаешь?
Проблемы только в релизе или в дебаге тоже?

__________________

Отправлено thambs 04-02-2013 в 16:47:

XaeroX

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

>_controlfp

что это?

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

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 04-02-2013 в 17:14:

Цитата:

thambs писал:
что это?

Получение (и изменение) контрольного слова сопроцессора. В частности, точность арифметики с плавающей точкой. Проверь, может она у тебя снижена в релизе (компилятор постарался).

__________________

Отправлено thambs 05-04-2013 в 01:15:

AAARGH!!! опять же! на этот раз искал 16 часов -- причём, такую идиотскую ошибку, что в жизни б на это место не подумал.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено pRoxxx 05-04-2013 в 06:36:

Контрольные значения, брекпоинты. Иногда в Релиз моде выдает ошибку не там где надо, тогда помогает Дебаг Мод, а иногда в Релизе крашится, а Дебаге работает, тогда чуть посложнее. Если проблемы с памятью, могу подключить Visual Leak Detector иль PVS studio.

Отправлено Дядя Миша 05-04-2013 в 15:31:

Как бы микрософт не хаяли но компилер у него явно получшы, чем этот GCC.

Отправлено XaeroX 05-04-2013 в 15:49:

Дядя Миша
На линупсе гцц - пожалуй, лучшее, что есть для плюсов.
Это когда кучи шаблонов и прочего гамна.
Для обычного си, имхо, особой разницы между конпилерами нет, ну окромя ICL, который сам умеет все известные SSE (но он платный, и разумеется, оптимизирует исключительно под интеловские процы).

Добавлено 05-04-2013 в 22:48:

Я под виндой проекты на С торадиционно конпилю MinGW, а на С++ - десятой студией. Под линупсом только GCC.

Добавлено 05-04-2013 в 22:49:

Кстати, консольный gdb очень понравился. И gprof тоже ничего. Но опять же - только для си-кода (рейтрейсеры там всякие и тому подобное). Навороченные проекты с классами и шаблонами я таки под студией дебажу.

__________________

Отправлено Дядя Миша 05-04-2013 в 16:54:

Для Си - да, но там слава богу от компилятора никакого западла ждать не приходится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 02-11-2013 в 18:13:

sqrt( 1./(8.*pi*eCGS**2)*( me*veSQUARE/ne + ma*viSQUARE/ni ) )

сместо ma стояло na. величины отличаются на ~30 порядков, причём результирующий эффект сам себя компенсирует так что заметить его очень трудно. две суток счёта коту под хвост. убейте меня кто ни будь.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 02-11-2013 в 18:31:

А вот поэтому и надо давать переменным понятные имена.
Например, m_flFrictionFraction

__________________

Отправлено Дядя Миша 02-11-2013 в 18:54:

XaeroX и функциям тоже. Например Sys_MonkeyShouldBeSpanked

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FreeSlave 02-11-2013 в 19:41:

С тех пор как начал мучить язык D, теперь в Си вставляю ассерты и пишу юниттесты, хотя на уровне языка такой поддержки нет.

Насчёт имён - XaeroX дело говорит. Понимаю, что в книжечках по матану алгоритмы наверно так и описаны, но в программировании всё-таки другие правила. И кстати, в книжках по математике из-за таких коротких названий тоже бывают ошибки, а потом сиди думай, то ли ты такой тупой, что не понимаешь, то ли просто опечатка.

Отправлено Дядя Миша 02-11-2013 в 19:54:

Цитата:

FreeSlave писал:
С тех пор как начал мучить язык D, теперь в Си вставляю ассерты и пишу юниттесты

Ну ассерты - дело нужное. У меня к примеру какой-то ассерт сработал через полтора года после написания кода.
А вот юнит-тесты занятие прямо скажем бесполезное.
Я еще могу понять, если вы написали фундаментальную функцию, типа strcpy или sincos, которая используется чуть менее чем везде и ошибка в ней способна угробить абсолютно всё. Но во всех остальных случаях оно лишь создаёт ложную иллюзию оттестированости.
Вот китайцы берут мотор от таёты, коробку от хонды, ходовку наверное сами делают по чьей-то лицензии. По отдельности всё классно, а на выходе почему-то GellyMK и прсти гспди GreatWall.
Да и все китайские разработки почему-то устроены из хороших стабильных модулей, которые кое-как вместе склеены.
Это всё очень ненадёжно. Самое надёжное тестирование - на конечных потребителях продукта. Такой подход не означает, что в продукте будут выловлены абсолютно все ошибки. Он всего лишь означает, что с ними не столкнутся конечные потребители - т.к. мы будем вылавливать именно то, на что они жалуются. Метод тоже неидеальный, но хотя бы народ доволен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ~ X ~ 12-11-2013 в 13:57:

Из серии "мыши кололись-давились".
Я тоже южу шестёрку. Потому что быстрая и потому что, бкьждлжд, срамная халва. Но некоторые баги в ней просто ДИКО БЕСЯТ. Например, рандомные ошибки в циклах for, когда новая переменная ВНЕЗАПНО в первой итерации принимает последнее значение.

Вообще против ошибок есть базовые приёмы:
- warning lever: over9000
- нормальные детальные имена переменных
- инициализация дефолтных значений и конструкторов классов
- ассерты (ерунда, но иногда может стать подсказкой)
- try...catch
- DBG_FORCEBREAK

Кстати, Ксайрокс, подскажи:
#ifdef _MSC_VER
#define DBG_FORCEBREAK _asm {int 3};// XDM3035
#else
#define DBG_FORCEBREAK ASSERT(0);// что вот здеся для мингвы и линуксов писать?
#endif
#else // !DEBUG

__________________
Минутка полезного:
Бесплатный UT-подобный Half-Life mod.
Бесплатный редактор для 32-битных текстур. Без дотнета.
Бесплатный IDE для любых компиляторов и ЯП.
Бесплатная Windows-подобная ОС.
Проверка грамматики русского языка.
Чат по hl[fx]: [email protected]

Отправлено XaeroX 12-11-2013 в 14:10:

Цитата:

~ X ~ писал:
Потому что быстрая и потому что, бкьждлжд, срамная халва.

Потому что ты лентяй.

Хлфх 0.7 я преспокойно собирал в 2010 студии, и всё шикарно работало. Не надо на халфу гнать.

Цитата:

~ X ~ писал:
// что вот здеся для мингвы и линуксов писать?

Так и быть, поделюсь секретом из волатилы.

C++ Source Code:

1	#if !defined(DEBUG_BREAK)

2	#if defined(_MSC_VER)

3	#if defined(_M_X64)

4	#define DEBUG_BREAK() __debugbreak()

#else

6	#define DEBUG_BREAK() do { __asm int 3 } while( 0 )

#endif

8	#elif defined(__GNUC__)

9	#define DEBUG_BREAK() __asm( "int $3\n" )

#endif

#endif

__________________

Отправлено Дядя Миша 12-11-2013 в 16:12:

PVS Studio и CPP Checker.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 12-11-2013 в 16:14:

Цитата:

XaeroX писал:
do { __asm int 3 } while( 0 )

А почему не __asm { int 3 } ?

Отправлено XaeroX 12-11-2013 в 19:43:

Government-Man
Подумай.

Добавлено 13-11-2013 в 01:43:

Кто ещё не знает, для чего прогрессивное человечество использует конструкцию do {} while (0)? Удивите старика.

__________________

Отправлено ~ X ~ 13-11-2013 в 06:43:

http://stackoverflow.com/questions/...s-technique-bad

я просто процитирую:

Цитата:

It depends on what the alternatives are. You have to admit that the code you posted is somewhat ugly. I wouldn't say it's clear. It's a kind of a hack. So if using some other coding solution would be worse, then ok. But if you have better alternative, don't let the excuse "it's good enough" comfort you.

Отправлено XaeroX 13-11-2013 в 09:41:

~ X ~
И чё к чему ты это процитировал?
Объясни, что ты имел в виду.

__________________

Отправлено thambs 08-01-2014 в 16:06:

FFFFFFUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU~~~~~~~~~~

я идиот. в одном месте вместо 0.25 стояло 0.75 а по результату хрен это заметишь.. так баг и висел. два месяца работы коту под хвост, всё надо пересчитывать.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 08-01-2014 в 16:08:

Цитата:

thambs писал:
две суток счёта коту под хвост

Цитата:

thambs писал:
два месяца работы коту под хвост

Прогресс налицо. %)
А на самом деле - совершенно нормальная ситуация. Я свои модели примерно так же пересчитывал на протяжении трёх лет.

__________________

Отправлено thambs 08-01-2014 в 16:36:

>Прогресс налицо. %)
а я знаю, следующей стадией будет:
>вся жизнь коту под хвост

~~останется только посмотреть розовых пони и застрелиться к чертям собачим.~~

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 08-01-2014 в 16:38:

У меня после просмотра пони багов меньше стало, кстати.

__________________

Отправлено Дядя Миша 08-01-2014 в 16:59:

Цитата:

XaeroX писал:
У меня после просмотра пони багов меньше стало, кстати.

зато глюков больше?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 08-01-2014 в 17:16:

Глюков вообще отродясь не было.

__________________

Отправлено thambs 14-11-2015 в 23:13:

всегда проверять граничные условия
ВСЕГДА ПРОВЕРЯТЬ ГРАНИЧНЫЕ УСЛОВИЯ
даже так:
ВСЕГДА ПРОВЕРЯТЬ ГРАНИЧНЫЕ УСЛОВИЯ, Б---ТЬ!

обнаружил у себя заразу, которая совершенно непредсказуемо гадила в самые неожиданные моменты. причём гадила так, что двое суток счёта, а потом внезапно(!) фэйл. а разгадка оказалась в самом неожиданном месте. массив с значениями магнитного поля:

Цитата:

NaN 271.757355 273.969788 275.843597 277.777863 279.766846 281.623810 283.402924 285.401306 286.591339 288.320343 289.984802 291.229919 292.246704 293.755280 294.821259 295.984772 296.737976 297.422638 298.063751 298.611176 299.167023 299.436188 299.828400 299.881775 300.000000 299.954559 299.481842 298.927734 298.668915 298.314636 297.713409 296.890533 295.800385 294.950104 293.605896 292.387726 291.286804 289.777954 288.516113 286.942169 285.262054 283.360718 281.684479 279.942688 278.154327 276.043732 273.921387 271.953064 270.020599 267.639038 265.813995 263.669037 261.433533 259.042572 256.974609 254.838394

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

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 15-11-2015 в 05:43:

thambs
У нана есть одно замечательное свойство, которое помогает в отладке. Любая операция нормального числа с наном даёт нан. Поэтому - лог, лог и ещё раз лог. Ну и assert( x == x ) не забывать.

Отправлено ~ X ~ 15-11-2015 в 08:43:

XaeroX чем "x == x" отличается от "x == NaN"?

Отправлено XaeroX 15-11-2015 в 08:50:

~ X ~
Тем, что второе не скомпилируется, выдав ошибку "NaN: undeclared identifier".

Отправлено ~ X ~ 15-11-2015 в 11:28:

XaeroX у тебя сегодня настроение совсем плохое? isnan - есть такая ф-я. Я бы предпочёл использовать её, а не x==x.

Отправлено XaeroX 15-11-2015 в 12:12:

Цитата:

~ X ~ писал:
у тебя сегодня настроение совсем плохое?

Когда ты пишешь чушь - оно у меня портится, факт.

Цитата:

~ X ~ писал:
isnan - есть такая ф-я. Я бы предпочёл использовать её, а не x==x.

А вместо if ( x ) ты пишешь if ( CrtIsValidPointer( x ) )?
Ты слышал про такое понятие, как пессимизация?

Отправлено ~ X ~ 15-11-2015 в 12:42:

Цитата:

XaeroX писал:
А вместо if ( x ) ты пишешь if ( CrtIsValidPointer( x ) )?

теперь буду.
А раньше писал if (x != NULL)// где NULL - это не 0, а специальная сверхсекретная хренота

Отправлено XaeroX 15-11-2015 в 12:54:

Цитата:

~ X ~ писал:
а специальная сверхсекретная хренота

В волатиле тоже она есть:

C++ Source Code:

1	#if defined(_MSC_VER)

2	#if (_MSC_VER < 1600)

3	#define NULLPTR NULL

#else

5	#define NULLPTR nullptr

#endif

7	#elif defined(__GNUC__)

8	#if (__GNUC__ < 4) \|\| (__GNUC__ == 4 && __GNUC_MINOR__ < 6) \|\| !defined(__GXX_EXPERIMENTAL_CXX0X__)

9	#define NULLPTR __null

#else

11	#define NULLPTR nullptr

#endif

#else

14	#define NULLPTR NULL

#endif

Временная зона GMT. Текущее время 13:44.

Показать все 49 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024