Исправление byko3y, (текущая версия) :
в санках делали инструмент под названием tsotool или что-то такое, смысл был в том, чтобы проверять непротиворечивость и согласованность обращений к общей памяти на многопроцессорных системах от санок, все это вроде благополучно похерили, но теория и алгоритмы в принципе могли бы помочь @byko3y попытаться потестировать его разделяемую память между процессами
Спасибо за ссылку, я про такую штуку еще не слышал. На самом деле, этот инструмент не проверяет непротиворечивость и несогласованность — он просто брутфорсом пытается угадать условия для воспроизведения бага, причем, сделать это быстрее, чем на обычной работающей софтине.
Здесь есть проблема, которую я недавно увидел в ядре линя, а именно — «наверное это будет работать». То есть, баги загоняются в области 1/100'000'000'000, когда за пятдесят лет работы он воспроизведется пару раз, которые оба спишут на аппаратный сбой. Вот если бага проявляется несколько раз в год — тогда зовут Торвальдса и он фиксит багу.
Я же, по крайней мере в своем проекте, проповедую иной подход: прохождение тестов не значит ничего; корректность работы определяется безупречной целостностью памяти по окончанию работы при условии прохождения работы по всем веткам, в том числе очень редким — для насильного захода в необычные ветки применяются отладочные флаги, активирующие ветку по условию вроде «rand() % 23 == 0». Вот чтобы эту штуку автоматизировать и дать хоть какую-то гарантию, что я не пропустил какую-то ветку или комбинацию веток, я бы и хотел какой-нибудь инструмент.
Исправление byko3y, :
в санках делали инструмент под названием tsotool или что-то такое, смысл был в том, чтобы проверять непротиворечивость и согласованность обращений к общей памяти на многопроцессорных системах от санок, все это вроде благополучно похерили, но теория и алгоритмы в принципе могли бы помочь @byko3y попытаться потестировать его разделяемую память между процессами
Спасибо за ссылку, я про такую штуку еще не слышал. На самом деле, этот инструмент не проверяет непротиворечивость и несогласованность — он просто брутфорсом пытается угадать условия для воспроизведения бага, причем, сделать это быстрее, чем на обычной работающей софтине.
Здесь есть проблема, которую я недавно увидел в ядре линя, а именно — «наверное это будет работать». То есть, баги загоняются в области 1/100'000'000'000, когда за пятдесят лет работы он воспроизведется пару раз, которые оба спишут на аппаратный сбой.
Я же, по крайней мере в своем проекте, проповедую иной подход: прохождение тестов не значит ничего; корректность работы определяется безупречной целостностью памяти по окончанию работы при условии прохождения работы по всем веткам, в том числе очень редким — для насильного захода в необычные ветки применяются отладочные флаги, активирующие ветку по условию вроде «rand() % 23 == 0». Вот чтобы эту штуку автоматизировать и дать хоть какую-то гарантию, что я не пропустил какую-то ветку или комбинацию веток, я бы и хотел какой-нибудь инструмент.
Исходная версия byko3y, :
в санках делали инструмент под названием tsotool или что-то такое, смысл был в том, чтобы проверять непротиворечивость и согласованность обращений к общей памяти на многопроцессорных системах от санок, все это вроде благополучно похерили, но теория и алгоритмы в принципе могли бы помочь @byko3y попытаться потестировать его разделяемую память между процессами
Спасибо за ссылку, я про такую штуку еще не слышал. На самом деле, этот инструмент не проверяет непротиворечивость и не согласованность — он просто брутфорсом пытается угадать условия для воспроизведения бага, причем, сделать это быстрее, чем на обычной работающей софтине.
Здесь есть проблема, которую я недавно увидел в ядре линя, а именно — «наверное это будет работать». То есть, баги загоняются в области 1/100'000'000'000, когда за пятдесят лет работы он воспроизведется пару раз, которые оба спишут на аппаратный сбой.
Я же, по крайней мере в своем проекте, проповедую иной подход: прохождение тестов не значит ничего; корректность работы определяется безупречной целостностью памяти по окончанию работы при условии прохождения работы по всем веткам, в том числе очень редким — для насильного захода в необычные ветки применяются отладочные флаги, активирующие ветку по условию вроде «rand() % 23 == 0». Вот чтобы эту штуку автоматизировать и дать хоть какую-то гарантию, что я не пропустил какую-то ветку или комбинацию веток, я бы и хотел какой-нибудь инструмент.