Error Handling

Generally, the program cannot recover from fatal errors. Memory errors are one of the most severe cause for fatal errors. Since it is expected that almost all calls to the memory manager must report an error and abort the program, the standard allocation functions of the memory manager perform this function for the caller, making its life much easier. If the memory manager fails to allocate memory, it reports an error and uses a longjmp to return to the top-level routine's error recovery routine. That routine is expected to sever all network connections, delete the entire database, use mi_mem_release_all to clear out the remaining arena, perhaps unload the raylib, and return a fatal-error code to the caller. Note that no calls may be used after mi_mem_release_all because all previously allocated memory that those calls may need has been released at that point.

The memory module does not guarantee that allocation failures are detected immediately. Many Unices always succeed in allocating virtual memory and defer allocating real memory or swap until the memory is accessed. If it turns out later that no real memory or swap space is available to perform the access, the operating system will kill the process, or it may kill another process that hogs the swap. Either way, the memory manager has no control over this. This is an extremely rare problem. The kernel's swap preallocation behavior can be altered by a system administrator.