Как диагностировать странную ошибку в состоянии гонки?

Question

Ошибка, которую мы отслеживаем, возникает в конкретной встроенной среде на основе VxWorks (поставщик изменил материал на неизвестное расширение и предоставляет уровень абстракции для большей части VxWorks).У нас есть две задачи с разными приоритетами, выполняемые примерно каждые 100 мс.Задача с более высоким приоритетом просто подсчитывает, добавляет добавляет, подсчитывает целое число (точно так же, как она делает что-нибудь), в то время как задача с более низким приоритетом создает строку, например:

std::string text("Some text");

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

При каждом запуске каждая задача делает это сто раз, так что вероятность возникновения состояния гонки выше.Приложение работает нормально в течение пары минут, а затем загружает процессор с 5% до 100% и остается там.Кажется, все время используется задачей, которая создала строку.До сих пор мы не смогли воспроизвести поведение без использования std::string.

Мы используем GCC 4.1.2 и работаем на VxWorks 5.5.Программа работает на Pentium III.

Я попытался проанализировать, что там происходит, но я не могу ввести ни один из string -методов с помощью отладчика, и добавление операторов print в basic-string некажется, работает (это был фон для этот мой вопрос ).Я подозреваю, что что-то там повреждает стек, что приводит к петле питания.У меня вопрос, есть ли какая-либо известная ошибка в старых версиях VxWorks, которая могла бы объяснить это?Если нет, есть ли у вас какие-либо дальнейшие предложения, как диагностировать это?Я могу получить разборки и дампы стека, но у меня нет опыта в интерпретации.Может ли кто-нибудь предоставить несколько указателей ?

Answer 1

Всякий раз, когда я вижу странное состояние гонки в системе VxWorks с необъяснимым поведением, моей первой мыслью всегда будет "VX_FP_TASK снова наносит удар!"Прежде всего вы должны проверить, создаются ли ваши потоки с флагом VX_FP_TASK в taskSpawn.

В документации говорится что-то вроде: «Это смертельно опасно - выполнять любые операции с плавающей запятой в задаче, созданной без опции VX_FP_TASK, и найти ее очень сложно».Теперь вы можете подумать, что вы вообще не используете регистры FP, но C ++ использует их для некоторой оптимизации, а для операций MMX (как вы, возможно, используете для добавления) требуется, чтобы эти регистры были сохранены.

Answer 2

Если я помню, vxWorks предоставляет определенные области памяти потоков (или, возможно, только одно местоположение). Эта функция позволяет указать область памяти, которая будет автоматически скрываться переключателями задач, чтобы при записи в поток значение сохранялось между переключателями задач. Это как дополнительный регистр сохранения / восстановления.

GCC использует одно из этих потоковых мест памяти для отслеживания стека исключений. Даже если вы иначе не используете исключения, есть некоторые ситуации (в частности, new, например, может вызываться конструктор std::string), которые неявно создают try/catch подобные среды, которые манипулируют этим стеком. В гораздо более старой версии gcc я видел, что в коде нет ничего плохого, формально не используется обработка исключений.

В этом случае решение заключалось в компиляции с -fno-exceptions для устранения всего этого поведения, после чего проблема исчезла.