1.11 Bugs

There are no known bugs outstanding, except for any that may be inherent in the external library functions. However, avram has been used most extensively on GNU/Linux systems, and the prospect of portability issues with new or lesser used features on other systems can’t be excluded.

Though not observed in practice, it’s theoretically possible to blow the stack by passing enough functions as arguments to library functions that pass more functions to library functions (e.g., by using nested calls to the gsl integration functions meant for a single variable to evaluate a very high dimensional multiple integral). In all other cases only dynamic heap storage or a constant amount of stack space is used. In particular, this issue is not relevant to virtual code applications that don’t use external libraries, or that don’t pass functions to them as arguments.

avram is designed to recover gracefully from memory overflows by always checking for NULL results from malloc() or otherwise trapping functions that allocate memory. In the event of an overflow, it conveys an appropriate error message to the virtual code application to be handled by the usual exception handling mechanisms. However, there is currently no way for a virtual code application to detect in advance whether sufficient memory is available, nor for it to resume normal operation once an exception occurs. Furthermore, it has been observed on some systems including Irix and 2.4 series Linux kernels that the avram process is killed automatically for attempting to allocate too much memory rather than given the chance to recover.

Please send bug reports to ursala-users@freelists.org or file an issue on the Avram github page.

This document was generated on November 8, 2012 using texi2html 1.82.