> [i]Если ты знаешь где он находится.[/i] - после того как Вы попали
> в исключение, то Вам уже известно какой поток, состояние регистров и
> стека. Чаще прочего этого достаточно чтобы определить, где проблема.

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

> Понятное дело, что может быть код, который случайным образом портит память: но
> такой код, как правило, сам довольно быстро вызывает исключения и всё
> становится более менее понятно.
> [i]с точностью до точного порядка инструкций[/i] - если нужно писать с точностью
> до порядка инструкций, то я пишу на ассемблере.
> я редко пишу на ассемблере.

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

> У меня наибольшие проблемы возникали когда время от времени программа неправильно работает(и
> никто толком ни в чем не уверен). Ничего не падает, но
> вроде бы иногда работает неправильно. И думай что-хочешь.

Угу. Это ещё хуже, потому что нет точного критерия "программа сработала неправильно". Сегфолт по-крайней мере окончателен. Но представь себе, что какая-то часть программы иногда работает неправильно, а другая часть иногда на это неправильно реагирует сегфолтом. И при этом неправильное поведение остаётся внутри программы незамеченным, если не было сегфолта. А если при этом неправильное поведение случается при каком-нибудь очень интересном стечении обстоятельств, которое происходит с частотой 0.0001, то есть один раз из 10000. И мало того, оно зависит от чего-нибудь, что меняется от запуска к запуску -- показания часов, состояние генератора случайных чисел, скорость чтения с жёсткого диска, переключение задач в точно заданный момент, обрыв tcp-соединения между входящими килобайтами с номерами 128*k+31 и 128*k+32 для любого целого k>0, или ещё что-нибудь в этом роде.

Представь себе это. Чуешь как интересно будет отлаживать? Особенно если ты не знаешь всех этих особенностей бага до того, как начал его ловить.