Как локализовать ошибку SIGSEGV?

[CRobin]

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

[Лекс Айрин]

Карандаш и пошаговое выполнение в "ручном" режиме.
Как правило, это ошибка неправильной работы с объектами/указателями.

[CRobin]

Лекс Айрин именно так. В ручном режиме не всегда есть возможность выполнить алгоритм, например, если имеет место обмен данными с другим приложением. Из-за такой опасности пропадает желание развивать приложение и реализовывать сложные схемы. Возможно всеже есть какой то выход?

[azsx]

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

[Лекс Айрин]

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

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

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

[CRobin]

Лекс Айрин я имел в виду, что наличие клиента или сервера (по сути второй стороны) может создавать логические ситуации, которые невозможно воспроизвести.

Добавлено спустя 4 минуты 48 секунд:
azsx логи как правило показывают ошибки, которые являются следствием искомой ошибки. Например, обращение к несуществующему элементу в модуле А, может спокойно вызвать сбой в модуле Б и модуле С. При этом большая опасность, если вы начнете исследовать модули Б и С, сломать то, что работает.

[azsx]

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

Не поверите и такие ситуации у меня бывали. Типа вот конкретная строка кода, до неё лог срабатывает, после неё лог уже не пишется. А строка как строка и ошибка ваще ниже по коду была. Вот в таких случаях сижу, разбираюсь в коде, который сам написал, ищу ошибку в этой строке или в коде который до этой строки следует и т.п. Конечно, если бы я на ассемблерный код глянул и сразу чувствовал бы где я сделал в паскалевском коде ошибку - было бы значительно проще.
Бывает и иначе. Написал алгоритм, программа каждые пару суток вылетает как часы. Я программу запускаю с bat файла, в нем цикл - вылетела, снова запускается. Да и нафиг надо искать проблему, прямо других занятий нет, кроме как доводить свой софт до совершенства.

[Лекс Айрин]

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

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

Можно запустить копию клиента/сервера у себя. И не говори, что поднять сервак это суперсложная проблема. Под виндой это, допустим, Денвер. Под линухой он идет в репах и его настройка, в принципе, не настолько сложна как представляется.

[CRobin]

да ладно... можно написать эмулятор

Конечно же можно, и даже нужно)) Но если процесс взаимодействия не линейный, то не возможно в принципе воспроизвести все игровые ситуации.

[Лекс Айрин]

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

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

[zub]

CRobin
>>Здравствуйте. Время от времени получаю такую коварную ситуацию.
Ситуация вполне обычная)) Баги всегда кажутся какимито "сказочными", а когда их найдешь оказываются глупыми
>>Если в логике программы содержится ошибка, отладчик ее не покажет
а посмотреть стек вызовов?
>>Кроме общей грамотности и хорошего знания языка, коим не обладаю.
Собрать программу с heaptrc - устранить ругань (при этом нужно чтобы программа штатно завершалась, а не падала, при падении будет куча лишней ругани на всю не освобожденную память)
Прогнать прогрпамму в valgrind - устранить ругань

azsx
>>Типа вот конкретная строка кода, до неё лог срабатывает, после неё лог уже не пишется. А строка как строка и ошибка ваще ниже по коду была.
Мистики тут быть неможет. После нахождения ошибки такое "невообразимое" поведение становится объяснимым и понятным
>>Да и нафиг надо искать проблему
Если даже программа одноразовая-ненужная, ошибку надо найти и устранить для приобретения соответствующего опыта
>>Конечно, если бы я на ассемблерный код глянул и сразу чувствовал бы где я сделал в паскалевском коде ошибку - было бы значительно проще.
Если ошибку не видно глядя на паскаль, то глядеть на асемблер вообще смысла нет.

[CRobin]

а когда их найдешь оказываются глупыми

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

[zub]

Везенью тут не место.

[CRobin]

zub спасибо за упоминания инструментов, буду гуглить

[azsx]

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