2. Error handing

Operations in the Memory Pool System that might fail return a result code of type mps_res_t, rather than a “special value” of the return type.

Success is always indicated by the result code MPS_RES_OK, which is defined to be zero. Other result codes indicate failure, and are non-zero.

The modular nature of the MPS means that it is not usually possible for a function description to list the possible error codes that it might return. A function in the public interface typically calls methods of an arena class and one or more pool classes, any of which might fail. The MPS is extensible with new arena and pool classes, which might fail in new and interesting ways, so the only future-proof behaviour is for a client program to assume that any MPS function that returns a result code can return any result code.

mps_res_t

The type of result codes. It is a transparent alias for int, provided for convenience and clarity.

A result code indicates the success or failure of an operation, along with the reason for failure. As with error numbers in Unix, the meaning of a result code depends on the call that returned it. Refer to the documentation of the function for the exact meaning of each result code.

The result codes are:

2.1. Result codes

MPS_RES_COMMIT_LIMIT

A result code indicating that an operation could not be completed as requested without exceeding the commit limit.

You need to deallocate something to make more space, or increase the commit limit by calling mps_arena_commit_limit_set().

MPS_RES_FAIL

A result code indicating that something went wrong that does not fall under the description of any other result code. The exact meaning depends on the function that returned this result code.

MPS_RES_IO

A result code indicating that an input/output error occurred. The exact meaning depends on the function that returned this result code.

MPS_RES_LIMIT

A result code indicating that an operation could not be completed as requested because of an internal limitation of the MPS. The exact meaning depends on the function that returned this result code.

MPS_RES_MEMORY

A result code indicating that an operation could not be completed because there wasn’t enough memory available.

You need to deallocate something or allow the garbage collector to reclaim something to free enough memory, or expand the arena (if you’re using an arena for which that does not happen automatically).

Note

Failing to acquire enough memory because the commit limit would have been exceeded is indicated by returning MPS_RES_COMMIT_LIMIT, not MPS_RES_MEMORY.

Running out of address space (as might happen in virtual memory systems) is indicated by returning MPS_RES_RESOURCE, not MPS_RES_MEMORY.

MPS_RES_OK

A result code indicating that an operation succeeded.

If a function takes an out parameter or an in/out parameter, this parameter will only be updated if MPS_RES_OK is returned. If any other result code is returned, the parameter will be left untouched by the function.

MPS_RES_OK is zero.

MPS_RES_PARAM

A result code indicating that an operation could not be completed as requested because an invalid parameter was passed to the operation. The exact meaning depends on the function that returned this result code.

MPS_RES_RESOURCE

A result code indicating that an operation could not be completed as requested because the MPS could not obtain a needed resource. The resource in question depends on the operation.

Two special cases have their own result codes: when the MPS runs out of committed memory, it returns MPS_RES_MEMORY, and when it cannot proceed without exceeding the commit limit, it returns MPS_RES_COMMIT_LIMIT.

This result code can be returned when the MPS runs out of virtual memory. If this happens, you need to reclaim memory within your process (as for the result code MPS_RES_MEMORY), or terminate other processes running on the same machine.

MPS_RES_UNIMPL

A result code indicating that an operation, or some vital part of it, is not implemented.

This might be returned by functions that are no longer supported, or by operations that are included for future expansion, but not yet supported.

2.2. Assertions

Bugs in the client program may violate the invariants that the MPS relies on. Most functions in the MPS (in most varieties; see below) assert the correctness of their data structures, so these bugs will often be discovered by an assertion failure in the MPS. The section Common assertions and their causes below lists commonly encountered assertions and explains the kinds of client program bugs that can provoke these assertions.

It is very rare for an assertion to indicate a bug in the MPS rather than the client program, but it is not unknown, so if you have made every effort to track down the cause (see Debugging with the Memory Pool System) without luck, get in touch.

If you are running your MPS-enabled program from Emacs via the compile command, you will probably want to recognize MPS assertions automatically, by adding the following to your .emacs:

(add-to-list 'compilation-error-regexp-alist
             '("MPS ASSERTION FAILURE: .*\n\\(.*\\)\n\\([0-9]+\\)" 1 2))

2.3. Common assertions and their causes

This section lists some commonly encountered assertions and suggests likely causes. If you encounter an assertion not listed here (or an assertion that is listed here but for which you discovered a different cause), please let us know so that we can improve this documentation.

dbgpool.c: fencepost check on free

The client program wrote to a location after the end, or before the beginning of an allocated block. See Debugging pools.

dbgpool.c: free space corrupted on release

The client program used an object after it was reclaimed. See Debugging pools.

format.c: SigCheck Format: format

The client program called mps_pool_create() for a pool class like AMC (Automatic Mostly-Copying) that requires a object format, but passed something other than a mps_fmt_t for this argument.

lockix.c: res == 0

lockw3.c: lock->claims == 0

The client program has made a re-entrant call into the MPS. Look at the backtrace to see what it was. Common culprits are format methods and stepper functions.

mpsi.c: SizeIsAligned(size, BufferPool(buf)->alignment)

The client program reserved a block by calling mps_reserve() but neglected to round the size up to the alignment required by the pool’s object format.

pool.c: (pool->class->attr & AttrALLOC) != 0

The client program called mps_alloc() on a pool that does not support this form of allocation. Use an allocation point instead.

poolams.c: !AMS_IS_INVALID_COLOUR(seg, i)

The client program failed to fix a reference to an object in an AMS (Automatic Mark and Sweep) pool, violating the tri-colour invariant that the MPS depends on for the correctness of its incremental garbage collection.

poolams.c: AMS_ALLOCED(seg, i)

The client program tried to fix a reference to a block in an AMS (Automatic Mark and Sweep) pool that died. This may mean that there was a previous collection in which a reference that should have kept the block alive failed to be scanned. Perhaps a formatted object was updated in some way that has a race condition?

2.4. Varieties

The MPS has three behaviours with respect to internal checking and telemetry, which need to be selected at compile time, by defining one of the following preprocessor constants. If none is specified then CONFIG_VAR_HOT is the default.

CONFIG_VAR_COOL

The cool variety is intended for development and testing.

All functions check the consistency of their data structures and may assert, including functions on the critical path.

All events are sent to the telemetry stream, including events on the critical path.

CONFIG_VAR_HOT

The hot variety is intended for production and deployment.

Some functions check the consistency of their data structures and may assert, namely those not on the critical path.

Some events are sent to the telemetry stream, namely those not on the critical path.

CONFIG_VAR_RASH

The rash variety is intended for mature integrations, or for developers who like living dangerously.

No functions check the consistency of their data structures and consequently there are no assertions.

No events are sent to the telemetry stream.