Errors

$Revision: 5.0.2.4 $

The document introduction.htm provides an overview of the Allegro CL documentation with links to all major documents. The document index.htm is an index with pointers to every documented object (operators, variables, etc.) The revision number of this document is below the title. These documents may be revised from time to time between releases.

1.0 Errors
2.0 Some common errors
    2.1 An unhandled error occurred during initialization: <message>
    2.2 Attempt to call <name> which is defined as a macro
    2.3 Gc errors
    2.4 Bus errors and segmentation violations
    2.5 Using package <package> results in name conflicts...

1.0 Errors

Errors in Allegro CL are handled by the condition system as described in the ANSI spec. Note too that some errors in Allegro CL are still classified as simple-errors when they should be classified otherwise.

The excl:errorset macro is preserved from earlier versions of Allegro CL although its functionality is completely superceded by the condition system. It is maintained for backward compatibility and its use in newly written code is not recommended.

Here is the condition type hierarchy. Allegro CL has some additional error types defined. They are marked with an *. The ones with links are further described. You can get the condition object associated with an error with the top-level command :error, which, besides printing the error message sets the value of * to the condition object.

condition
  advance-warning *
  input-edit *
  ics-dependent-classa *
  ics-dependent-classb *
  compiler-note *
  serious-condition
    storage-condition
    error
      type-error
        case-failure *
        simple-type-error
      stream-error
        stream-closed-error *
        end-of-file
        reader-error (also subclass of parse-error)
      parse-error
        reader-error (also subclass of stream-error)
      operating-system-signal *
        synchronous-operating-system-signal *
        asynchronous-operating-system-signal *
          interrupt-signal *
      package-error
        package-locked-error *
      file-error
      cell-error
        unbound-slot
        undefined-function
        unbound-variable
      print-not-readable
      arithmetic-error
        floating-point-inexact
        floating-point-invalid-operation
        floating-point-underflow
        floating-point-overflow
        division-by-zero
      compiler-not-available-error *
      program-error
      control-error
      simple-error
      socket-error *
  break
    simple-break *
  warning
    compiler-not-available-warning *
    simple-warning
    style-warning
      ineffective-decalation-warning *
         float-declaration-unused-warning *
      compiler-undefined-functions-called-warning *
      compiler-no-in-package-warning *
  simple-condition
    simple-type-error
    simple-error
    simple-break *
    simple-warning

2.0 Some common errors

We list here some common error messages. This list is by no means exhaustive and we only give a brief description of the likely cause. Error messages start with Error:, but we leave that out here. Names (of functions, symbols, etc.) that appear in error messages are replaced with <name> or some other generic placeholder.

2.1 An unhandled error occurred during initialization: <message>

This is printed when an error occurrs while Lisp was running through its startup procedure. <message> is the error message generated by the actual error. The startup fails as a result of the error. Assuming the startup procedure has not been changed, these cannot be the cause of this error:

Reading an initialization (.clinit.cl, clinit.cl or the sys:siteinit.cl) file. If an error reading one of these files is encountered, the error is reported and further reading of the file is aborted, but otherwise the error is ignored.
Inability to find a loaded .so/.sl/.dll file. A warning but no error is signaled if the file cannot be found. Note that an error might be caused if a foreign function whose code resides in the missing .so file is called during startup.
A problem with *restart-init-function* or *restart-app-function*. These functions are called outside the handler which prints the An unhandled error ... message.

These may be the cause:

An error evaluating a -e <form> command-line argument. Try to start without the -e arguments.
An error performing the *restart-actions*. Try to start with the following on the command line (it suppresses any restart actions). Be sure to wrap the parentheses with ' marks or other shell-specific quotation-like marks.
-e (setq excl:*restart-actions* nil)
An error evaluating the form that is the value of the ACL_STARTUP_HOOK environment variable. Try restarting after unsetenv'ing that variable.

2.2 Attempt to call <name> which is defined as a macro

Code calling <name> was compiled before <name> was defined as a macro is the cause.

user(1): (defun foo () (bar) 10) foo user(2): (compile *) Warning: While compiling these undefined functions were referenced: bar. foo nil nil user(3): (defmacro bar nil nil) bar user(4): (foo) Error: Attempt to call bar which is defined as a macro. [condition type: program-error] [1] user(5):

The example above shows the definitions typed to the top-level, but this error is most commonly caused when files are compiled in the wrong order.

2.3 Gc errors

See 9.0 gc errors in gc.htm where these errors are discussed.

2.4 Bus errors and segmentation violations

Bus errors and segmentation violations are standard OS errors. They are not specific to Lisp. Typically, a bus error is caused by an attempt to write to read-only memory while a segmentation violation is an attempt to access memory that does not exist. You may see them signaled in Lisp, usually when an error is signaled from code compiled at high speed and low safety (so standard Lisp error checkers are not used). If you see such an error, try recompiling code at higher safety and lower speed (in particular, make comp:trust-declarations-switch return nil) and see whether the error persists.

**2.5 Using package <package> results in name conflicts...**

Suppose you try to call a function in a currently-unused package but forget the package qualifier. For example, suppose you called process-run-function without the mp: and the multiprocessing package is not used. You get an error about process-run-function not having a function definition (as expected). Then you use the multiprocessing package by evaluating (use-package :mp). The following error will be signaled:

Error: Using package `MULTIPROCESSING' results in name conflicts for these symbols: PROCESS-RUN-FUNCTION [condition type: PACKAGE-ERROR] Restart actions (select using :continue): 0: Unintern the conflicting symbols in the `MULTIPROCESSING' package.

In order for process-run-function typed without a package qualifier to be mp:process-run-function, enter

:continue 0

The message is confusing but that is the right choice.