Неожиданное обнуление семафора, Указатель семафора сам по себе становится NULL Опции

[turnon]

Использую рекурсивный семафор. Иногда (1-2 раза в неделю при работе 7*24) указатель семафора становится NULL сам по себе.
Определяю это срабатыванием ассерта, FreeRTOS\Source\queue.c, line 491.

FreeRTOS V8.2.2, IAR.

Не пойму, что может такого происходить, что приводит к обнуления переменной ассерта?
Переполнение стека? Это контролируется vApplicationStackOverflowHook и vApplicationMallocFailedHook.
И от HighWaterMark до конца стека еще больше 20%.

Создание семафора:

_semaphore = xSemaphoreCreateRecursiveMutex();
assert(_semaphore != NULL);

_semaphore объявлена volatile.

Использование семафора:

assert(xSemaphoreTakeRecursive(_semaphore, (portTickType)portMAX_DELAY) == pdTRUE);
...
assert(xSemaphoreGiveRecursive(_semaphore) == pdTRUE);

Или так:

assert(xSemaphoreTakeRecursive(_semaphore, (portTickType)portMAX_DELAY) == pdTRUE);
...
assert(xSemaphoreTakeRecursive(_semaphore, (portTickType)portMAX_DELAY) == pdTRUE);
...
assert(xSemaphoreGiveRecursive(_semaphore) == pdTRUE);
...
assert(xSemaphoreGiveRecursive(_semaphore) == pdTRUE);

[den_po]

Использование семафора:

assert(xSemaphoreTakeRecursive(_semaphore, (portTickType)portMAX_DELAY) == pdTRUE);

про обнуление не скажу, а вот вызовы функций в ассерты заворачивать нельзя

[turnon]

а вот вызовы функций в ассерты заворачивать нельзя

Почему?

[den_po]

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

[turnon]

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

Ну как бы я знаю что у меня в assert, и assert - это уже мой вариант, по умолчанию идет макрос с именем assert_param. И даже по умолчанию там есть реализация - бесконечный цикл.

[zltigo]

Переполнение стека? Это контролируется vApplicationStackOverflowHook и vApplicationMallocFailedHook.
И от HighWaterMark до конца стека еще больше 20%.

Кроме стеков задач есть еще и другие стеки. Но поскольку Вы жалуетесть только на одну переменную, хотя рядом с ней еще и явно другие находятся, а также то, что в результате всяких Ваших отладочных действий положение этой переменной в памяти скорее всего менялось, то представляется невероятным, что каким-то невообразимым способом забивается именно эта одна переменная и именно нулем, где-бы она в памяти не находилась. Посему, хотите верьте, хотите нет, но затираете Вы явным образом сами. Ну или не совсем явным. Смотрите, например, на какой-нибудь массив расположенный рядом с этой переменной.

[turnon]

Посему, хотите верьте, хотите нет, но затираете Вы явным образом сами. Ну или не совсем явным. Смотрите, например, на какой-нибудь массив расположенный рядом с этой переменной.

Спасибо, уже по теме. А как понять что рядом?

[zltigo]

Спасибо, уже по теме. А как понять что рядом?

MAP файл линкера.

[megajohn]

Спасибо, уже по теме. А как понять что рядом?

можно через JTAG поставить DataBreakpoint и не париться

[zltigo]

можно через JTAG поставить DataBreakpoint и не париться

Я бы не характеризовал словами "не париться" подключение где-нибудь на объекте в городе мухосранске царевопропойской губернии к JTAG (если он есть), отладчика, компьютера, установки софтины, обучение персонала и недельное ожидание события

[turnon]

MAP файл.

Уж простите за безграмотность. Что-то не нахожу в map файле полей объекта. Вот в Log есть поле _semaphore, а в map файле _semaphore не нахожу, как и остальных полей объекта.

[zltigo]

Что-то не нахожу в map файле полей объекта. Вот в Log есть поле _semaphore, а в map файле _semaphore не нахожу, как и остальных полей объекта.

Мне трудно понять то, что Вы пишите . Я не знаю, что такое Вы назвали "Log" и "поле объекта". Если _semaphore элемент структуры, то в map будет адрес и размер структуры.
Выложите map файл - посмотрю.

[turnon]

Мне трудно понять то, что Вы пишите . Я не знаю, что такое Вы назвали "Log" и "поле объекта". Если _semaphore элемент структуры, то в map будет адрес и размер структуры.
Выложите map файл - посмотрю.

Вот для примера сделал минимальный проект в IAR (пристегнутый zip). empty\tmp\Debug\List\Project.map.
В объекте gLog есть поле _inited и _fileSpec, а в map-файле этих полей в явном виде нет. Почему?
 empty.zip ( 21.63 килобайт ) Кол-во скачиваний: 50


Сообщение отредактировал turnon - Sep 30 2015, 10:46

[den_po]

Ну как бы я знаю что у меня в assert, и assert - это уже мой вариант, по умолчанию идет макрос с именем assert_param. И даже по умолчанию там есть реализация - бесконечный цикл.

Если речь об исходниках FreeRTOS, то там используется макрос configASSERT, и именно по умолчанию там реализация - "ничего".
FreeRTOS\Source\include\FreeRTOS.h:

Код

#ifndef configASSERT
    #define configASSERT( x )
    #define configASSERT_DEFINED 0
#else
    #define configASSERT_DEFINED 1
#endif

Да, исправляюсь, в assert и подобные макросы заворачивают вызовы функций, но только те, удаление которых не влияет на ход работы программы. Это точно не ваш случай. В вашем случае нужно сохранять результат вызова в переменные и в ассертах использовать именно их.
Попробуйте скомпилировать ваш проект в релизной конфигурации (с объявленным в настройках препроцессора макросом NDEBUG) и убедитесь.

[turnon]

Если речь об исходниках FreeRTOS, то там используется макрос configASSERT, и именно по умолчанию там реализация - "ничего".
FreeRTOS\Source\include\FreeRTOS.h:

Код

#ifndef configASSERT
    #define configASSERT( x )
    #define configASSERT_DEFINED 0
#else
    #define configASSERT_DEFINED 1
#endif

Считаю легкомысленным оставлять пустую реализацию configASSERT. configASSERT у меня равен assert.

В вашем случае нужно сохранять результат вызова в переменные и в ассертах использовать именно их.
Попробуйте скомпилировать ваш проект в релизной конфигурации (с объявленным в настройках препроцессора макросом NDEBUG) и убедитесь.

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

в assert и подобные макросы заворачивают вызовы функций, но только те, удаление которых не влияет на ход работы программы.

assert - это проверка "контракта". Если assert не прошел - дальнейшее выполение программы не имеет смысла.

[den_po]

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

assert - часть стандартной библиотеки, что на него влияет, описано в стандарте.
Рассчитывать, что ваш код всегда будет работать с перепиленной вами версией макроса, - раскидывать грабли.

assert - это проверка "контракта". Если assert не прошел - дальнейшее выполение программы не имеет смысла.

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

[turnon]

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

assert применяется для проверки критичных условий, выход за которые означает крах.
Если assert сработал - дальнейшее выполнение программы опасно, может привести к непредсказуемым последствиям. При сработке assert правильное поведение (имхо) - фиксация файла и строки в энергонезависимой памяти и ресет.

[den_po]

assert применяется для проверки критичных условий, выход за которые означает крах.

Нет. Ассерт - просто средство отладки. Он нужен программисту, но никак не конечному пользователю.

Если assert сработал - дальнейшее выполнение программы опасно, может привести к непредсказуемым последствиям. При сработке assert правильное поведение (имхо) - фиксация файла и строки в энергонезависимой памяти и ресет.

Если б всё было так, всякие мобильники и телевизоры постоянно бы висли или вырубались. Ну и в иных местах просто были бы тормознее.

[zltigo]

Вот для примера сделал минимальный проект в IAR (пристегнутый zip). empty\tmp\Debug\List\Project.map.
В объекте gLog есть поле _inited и _fileSpec, а в map-файле этих полей в явном виде нет. Почему?

Почему УЖЕ писал:

Если _semaphore элемент структуры, то в map будет адрес и размер структуры

То-же естесественно, относится к любым объектам. Данные объекта gLog в map есть - 44 байта. Расположение переременных Вы сами задали:

class Log
{
private:
int _inited;
char _fileSpec[40];

Так-что что может быть непонятным-то? В структурах и классах могли-бы вообще и map не смотреть - Вы же своими собственными руками описали что рядом с чем находится.

Посмотите на класс в Вы который зарыли _semaphore и все будет ясно.

[turnon]

Данные объекта gLog в map есть - 44 байта. Расположение переременных Вы сами задали

А, получается просто в виде адресов. Предполагал что там будут имена переменных, а имен там нет.

Нет. Ассерт - просто средство отладки. Он нужен программисту, но никак не конечному пользователю.

Конечному пользователю и дебаггер не нужен. Ему нужен корректно работающий девайс.
Нет программ без ошибок. Вы же не будете утверждать обратное?

Если б всё было так, всякие мобильники и телевизоры постоянно бы висли или вырубались. Ну и в иных местах просто были бы тормознее.

Отсюда я делаю вывод, что в мобильниках и телевизорах куча ассертов, которые отключены из-за того, что если бы они были включены, мобильники и телевизоры постоянно бы висли или вырубались?

Посему, хотите верьте, хотите нет, но затираете Вы явным образом сами. Ну или не совсем явным. Смотрите, например, на какой-нибудь массив расположенный рядом с этой переменной.

Действительно обнаружил неверную трактовку размера массива. Массив состоит из uint64, а я его размер узнавал с помощью sizeof, без учета что размер элемента не 1 байт... Сказывается очень много работы со строками, где sizeof и равен размеру массива.

Мораль - если что-то не работает, начинайте с того места, где это не работает. А не с подозрений на компилятор, гейтса и фазу луны.

Но зато в процессе открыл для себя map-файлы. И раньше знал что есть что-то такое, но не лазил. А в map файле очень хорошо видно расход ОЗУ по модулям и переменным. Правда жаль что в map файле нет имен полей (переменных) объекта, только методы и глобальные переменные.

можно через JTAG поставить DataBreakpoint и не париться

Отличная штука, и применял же такое в разработке для ПК, но тут как-то не догадался.

[den_po]

Конечному пользователю и дебаггер не нужен. Ему нужен корректно работающий девайс.
Нет программ без ошибок. Вы же не будете утверждать обратное?

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

Отсюда я делаю вывод, что в мобильниках и телевизорах куча ассертов, которые отключены из-за того, что если бы они были включены, мобильники и телевизоры постоянно бы висли или вырубались?

Отключены они из-за того, что пользователю они ни к чему. Лучше пользователю от них не станет, а хуже может.
Они и разработчикам не нужны в большинстве случаев. Я не про ассерты вообще и разработчиков вообще, я про конкретно ситуацию с мобилками и телевизорами. У разработчиков/тестеров есть дебаг сборки прошивок, но и там включают ассерты не везде, а лишь в части модулей/библиотек.

Закруглюсь, пожалуй, с этой темой. Сказал уже всё, что мог, нового ничего не добавлю.

[turnon]

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

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

А иначе разработчик неправильно применяет ассерты.

Сообщение отредактировал turnon - Sep 30 2015, 21:16