Safely Exiting to a Particular State in Case of Error

Question

When writing code I often have checks to see if errors occurred. An example would be:

char *x = malloc( some_bytes ); 
if( x == NULL ){
    fprintf( stderr, "Malloc failed.\n" ); 
    exit(EXIT_FAILURE); 
}

I've also used strerror( errno ) in the past.

I've only ever written small desktop appications where it doesn't matter if the program exit()ed in case of an error.

Now, however, I'm writing C code for an embedded system (Arduino) and I don't want the system to just exit in case of an error. I want it to go to a particular state/function where it can power down systems, send error reports and idle safely.

I could simply call an error_handler() function, but I could be deep in the stack and very low on memory, leaving error_handler() inoperable.

Instead, I'd like execution to effectively collapse the stack, free up a bunch of memory and start sorting out powering down and error reporting. There is a serious fire risk if the system doesn't power down safely.

Is there a standard way that safe error handling is implemented in low memory embedded systems?

EDIT 1: I'll limit my use of malloc() in embedded systems. In this particular case, the errors would occur when reading a file, if the file was not of the correct format.

Answer 1

Maybe you're waiting for the Holy and Sacred setjmp/longjmp, the one who came to save all the memory-hungry stacks of their sins?

#include <setjmp.h>

jmp_buf jumpToMeOnAnError;
void someUpperFunctionOnTheStack() {
    if(setjmp(jumpToMeOnAnError) != 0) {
        // Error handling code goes here

        // Return, abort(), while(1) {}, or whatever here...
    }

    // Do routinary stuff
}

void someLowerFunctionOnTheStack() {
    if(theWorldIsOver)
       longjmp(jumpToMeOnAnError, -1);
}

Edit: Prefer not to do malloc()/free()s on embedded systems, for the same reasons you said. It's simply unhandable. Unless you use a lot of return codes/setjmp()s to free the memory all the way up the stack...

Answer 2

If your system has a watchdog, you could use:

char *x = malloc( some_bytes ); 
assert(x != NULL);

The implementation of assert() could be something like:

#define assert (condition) \
    if (!(condition)) while(true)

In case of a failure the watchdog would trigger, the system would make a reset. At restart the system would check the reset reason, if the reset reason was "watchdog reset", the system would goto a safe state.

update

Before entering the while loop, assert cold also output a error message, print the stack trace or save some data in non volatile memory.

Answer 3

Is there a standard way that safe error handling is implemented in low memory embedded systems?

Yes, there is an industry de facto way of handling it. It is all rather simple:

• For every module in your program you need to have a result type, such as a custom enum, which describes every possible thing that could go wrong with the functions inside that module.
• You document every function properly, stating what codes it will return upon error and what code it will return upon success.
• You leave all error handling to the caller.
• If the caller is another module, it too passes on the error to its own caller. Possibly renames the error into something more suitable, where applicable.
• The error handling mechanism is located in main(), at the bottom of the call stack.

This works well together with classic state machines. A typical main would be:

void main (void)
{
  for(;;)
  {
    serve_watchdog();

    result = state_machine();

    if(result != good)
    {
      error_handler(result);
    }
  }
}

---

You should not use malloc in bare bone or RTOS microcontroller applications, not so much because of safety reasons, but simple because it doesn't make any sense whatsoever to use it. Apply common sense when programming.

Answer 4

Use setjmp(3) to set a recovery point, and longjmp(3) to jump to it, restoring the stack to what it was at the setjmp point. It wont free malloced memory.

Generally, it is not a good idea to use malloc/free in an embedded program if it can be avoided. For example, a static array may be adequate, or even using alloca() is marginally better.

Answer 5

to minimize stack usage:

write the program so the calls are in parallel rather than function calls sub function that calls sub function that calls sub function.... I.E. top level function calls sub function where sub function promptly returns, with status info. top level function then calls next sub function... etc

The (bad for stack limited) nested method of program architecture:

top level function
    second level function
        third level function
            forth level function

should be avoided in embedded systems

the preferred method of program architecture for embedded systems is:

top level function (the reset event handler)
    (variations in the following depending on if 'warm' or 'cold' start)
    initialize hardware
    initialize peripherals
    initialize communication I/O
    initialize interrupts
    initialize status info
    enable interrupts
    enter background  processing

interrupt handler
    re-enable the interrupt
    using 'scheduler' 
        select a foreground function 
        trigger dispatch for selected foreground function        
    return from interrupt

background processing 

(this can be, and often is implemented as a 'state' machine rather than a loop)
    loop:
        if status info indicates need to call second level function 1 
            second level function 1, which updates status info
        if status info indicates need to call second level function 2
            second level function 2, which updates status info
        etc
    end loop:

Note that, as much as possible, there is no 'third level function x'

Note that, the foreground functions must complete before they are again scheduled.

Note: there are lots of other details that I have omitted in the above, like

kicking the watchdog, 
the other interrupt events,
'critical' code sections and use of mutex(),
considerations between 'soft real-time' and 'hard real-time',
context switching
continuous BIT, commanded BIT, and error handling 
etc