Исправление io, (текущая версия) :
К сожалению printf и gdb не всегда успешны. Но вот дополнить их можно. Сам предпочитаю более активные методы отладки (обычно код оказвается чужой - кто его разберет, когда автор маньяк). Посему для особо злобных случаев не разбираемых статикой:
1. Использование дампа в память вместо printf (обычно аналогом дабы потом все было readable, т.е. указатель на формат + пачка параметров). Максимально корректная работа с кольцевым буфером дабы исключить наложения, некорректную историю и т.п. Обычный printf бывает сильно искажает картинку, что-то падает, но никакого отношения к конкретной проблеме не имеет. Хотя пару дней назад наблюдал как увеличивает вероятность падения (вот та ли причина?). Колечко также позволяет не ковыряться в огромной распечатке параллельных выводов, когда ошибка бывает раз в 8-15 часов. Главное суметь извлечь.
2. Добавление процедур, которые спопобны либо проверить консистентность текущего состояния, либо как минимум распечатать по максимуму все что нужно (и, в частности, кольцевой буфер).
3. Наличие возможности обращения к предыдущим процедупам по сигналам извне: запуск проверки из отладчика или как минимум установка/сброс флага сбора инфы из отладчика, периодический запуск средств проверки состояния/зависона/консистентности (аналогично по вводу, watchdog-у, посылке сигнала извне и т.п.).
4. Здравое недоверие (без фатальной паранои) к чужим thread save, SMP safe библиотекам. Вот заглянул позавчера в ассемблер одной и стало грустно - SMP uncompatible.
5. Иногда привычное действие (например, кажущееся очевидно атомарным, типа запись числа в память) так забавно искажается компилятором при определенных опциях. Или генерируется не signal-safe код.
6. А вообще это все настолько зависит от приложения ....
Исправление io, :
К сожалению printf и gdb не всегда успешны. Но вот дополнить их можно. Сам предпочитаю более активные методы отладки (обычно код оказвается чужой - кто его разберет, когда автор маньяк). Посему для особо злобных случаев не разбираемых статикой:
1. Использование дампа в память вместо printf (обычно аналогом дабы потом все было readable, т.е. указатель на формат + пачка параметров). Максимально корректная работа с кольцевым буфером дабы исключить наложения, некорректную историю и т.п. Обычный printf бывает сильно искажает картинку, что-то падает, но никакого отношения к конкретной проблеме не имеет. Хотя пару дней назад наблюдал как увеличивает вероятность падения (вот та ли причина?). Колечко также позволяет не ковыряться в огромной распечатке параллельных выводов, когда ошибка бывает раз в 8-15 часов. Главное суметь извлечь.
2. Добавление процедур, которые спопобны либо проверить консистентность текущего состояния, либо как минимум распечатать по максимуму все что нужно (и, в частности, кольцевой буфер).
3. Наличие возможности обращения к предыдущим процедупам по сигналам извне: запуск проверки из отладчика или как минимум установка/сброс флага сбора инфы из отладчика, периодический запуск средств проверки состояния/зависона/консистентности (аналогично по вводу, watchdog-у, посылке сигнала извне и т.п.).
4. Здравое недоверие (без фатальной паранои) к чужим thread save, SMP safe библиотекам. Вот заглянул позавчера в ассемблер одной и стало грустно - SMP uncompatible.
5. А вообще это все настолько зависит от приложения ....
Исходная версия io, :
К сожалению printf и gdb не всегда успешны. Но вот дополнить их можно. Сам предпочитаю более активные методы отладки (обычно код оказвается чужой - кто его разберет, когда автор маньяк). Посему для особо злобных случаев не разбираемых статикой:
1. Использование дампа в память вместо printf (обычно аналогом дабы потом все было readable, т.е. указатель на формат + пачка параметров). Максимально корректная работа с кольцевым буфером дабы исключить наложения, некорректную историю и т.п. Обычный printf бывает сильно искажает картинку, что-то падает, но никакого отношения к конкретной проблеме не имеет. Хотя пару дней назад наблюдал как увеличивает вероятность падения (вот та ли причина?). Колечко также позволяет не ковыряться в огромной распечатке параллельных выводов, когда ошибка бывает раз в 8-15 часов. Главное суметь извлечь.
2. Добавление процедур, которые спопобны либо проверить консистентность текущего состояния, либо как минимум распечатать по максимуму все что нужно (и, в частности, кольцевой буфер).
3. Наличие возможности обращения к предыдущим процедупам по сигналам извне: запуск проверки из отладчика или как минимум установка/сброс флага сбора инфы из отладчика, периодический запуск средств проверки состояния/зависона/консистентности (аналогично по вводу, watchdog-у, посылке сигнала извне и т.п.).
4. Здравое недоверие (бкз фатальной паранои) к чужим thread save, SMP safe библиотекам. Вот заглянул позавчера в ассемблер одной и стало грустно - SMP uncompatible.
5. А вообще это все настолько зависит от приложения ....