Function with __noreturn__ attribute stops other threads from running

We are currently using FreeRTOS and FreeModbus TCP in Atmel Studio. We recently found an issue that causes our system to hang without triggering a WD reset of the system which is an indication that our WD task as well as other tasks that could trigger WD resets were not running.
This condition happened when an assertion configure as noreturn was true in the FreeModbus library:
void _EXFUN(__assert_func, (const char *, int, const char *, const char *)
_ATTRIBUTE ((noreturn)));

We do not see any of the feedback from the tasks in our system that would indicate they still running when the above assertion condition is met. Should other tasks still running in the background? How does the noreturn attribuate could affect the OS?

Thank you!!

The typical operation of an assert is to stop the WHOLE program, not just that task so that it is easy to see what assert fired.

An assert generally is testing for something that SHOULD NOT HAPPEN, and if it does, there is a fundamental error in logic or operation, so continued operation is questionable, and also makes it harder to see the assert condition that failed.

If you have a real watchdog (hardware) then that generally should fire, but if you have a software only watchdog, the assert function could well block that from running.

That would seem to defeat the purpose of a watchdog, which should automatically cause a reset when the systems hangs, rather than be prevented from causing a reset because the system has hanged.

To add to richard-damon - this question cannot be answered without knowing how the assert is defined. If, as is commonly the case, the assert is defined to bring the whole system to a halt then I would not expect other tasks to be running in the background - but there are many ways to implement the assert handler.

Thank you for your feedback @richard-damon and @rtel.

And as a small point of information, it isn’t the ‘noreturn’ attribute that is doing this, that just tells the compiler that the function being called isn’t going to return so as to affect certain warnings. What is stopping things is the function being called, which typically for and assert endpoint will maybe print out a message, and then disable interrupts and wait in place to halt the system hard. On a big machine operating system, it will tend to just abort the current process and return to the operating system, but under FreeRTOS that isn’t really applicable, as your program isn’t running ‘under’ FreeRTOS but is running with FreeRTOS as part of the program.