Использую рекурсивный семафор. Иногда (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);

Нажмите для просмотра прикрепленного файла

Нажмите для просмотра прикрепленного файла

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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

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

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


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

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

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

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

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

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



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


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



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

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

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




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

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


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

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

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

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