Allegro CL version 10.1
Unrevised from 10.0 to 10.1.
10.0 version


This document contains the following sections:

1.0 Errors
   1.1 More on cl:stream-error
2.0 Some common errors
   2.1 An unhandled error occurred during initialization:
   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...
3.0 Type errors in sequence functions: fastseq and safeseq

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 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.

  advance-warning *
  input-edit *
  ics-dependent-classa *
  ics-dependent-classb *
  compiler-note *
        case-failure *
        stream-closed-error *
        reader-error (also subclass of parse-error)
        socket-error *
        errno-stream-error *
        reader-error (also subclass of stream-error)
      operating-system-signal *
        synchronous-operating-system-signal *
        asynchronous-operating-system-signal *
          interrupt-signal *
        package-locked-error *
        file-does-not-exist-error *
          autoload-file-does-not-exist-error *
        floating-point-underflow [see note after table]
      compiler-not-available-error *
      socket-error *
      syscall-error *
      winapi-error *
    break-condition *
    compiler-not-available-warning *
    incompatible-conformance-change-warning *
      ineffective-declaration-warning *
      compiler-undefined-functions-called-warning *
      compiler-no-in-package-warning *
      compiler-unreachable-code-warning *
      compiler-inconsistent-name-usage-warning *
    simple-break *

Table Notes

floating-point-underflow is not usually signaled because most operating systems silently replace an underflow with zero without further action.

1.1 More on cl:stream-error

The stream-error class, as implemented in Allegro CL, has these slots:

With the new stream-error conditions and slots, Allegro CL classifies stream error situations when possible, relying on a catch-all condition to hold errno returns that could not be classified. A user might want to do handler-binds on the condition subclasses, or on the stream-error condition and then test the identifier slot. All stream conditions have such an identifier slot, but some conditions (especially the catch-all errno-stream-error condition) may not fill it in.

In particular, when a system operation returns an errno value, it is looked up to see if it is a socket-error, and if so, a socket-error condition is created. It is intended then that other errno classifications will be tried. If no classification can be made, then an errno-stream-error condition is created. Its identifier slot is set to :unknown, but an attempt is made to find out from the operating system what the string for such an error is, and that is stored into the condition in the string slot, for easier human identification.

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:

This is printed when an error occurs 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:

These may be the cause:

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)
user(2): (compile *)
Warning: While compiling these undefined functions were referenced: bar.
user(3): (defmacro bar nil nil)
user(4): (foo)
Error: Attempt to call bar which is defined as a macro.
   [condition type: undefined-function]
[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 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 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 from the `COMMON-LISP-USER' package.

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

:continue 0

See the top-level command :continue.

Note that in earlier (than 6.1) releases of Allegro CL, the error message was:

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.

Most users found that description of what happens when :continue 0 is entered confusing, and were unable to tell from the message what action would produce the desired result. The action is still :continue 0. It is hoped the revised message makes that more clear.

3.0 Type errors in sequence functions: fastseq and safeseq

Many Common Lisp sequence function are sensitive to the type of their arguments. Consider the following incorrect forms:

(make-list nil)  ;; argument should be an integer. NIL is illegal
(elt #(1 2 3) nil) ;; second argument should be an integer. 
                   ;; NIL is illegal
(mapcar #'alpha-char-p "N ")  ;; second argument should be a list
                              ;; not a string

In each case, the argument given is wrong, but not unreasonable, and a programmer could carelessly but understandably make the errors shown (indeed, all these errors come from our support files). But note they reached our support files because the result (in earlier releases of Allegro CL) of evaluating the erroneous form was more serious than expected: rather than simply signaling an error, Lisp would in some cases enter an infinite loop and have to be interrupted.

In safe code, sequence functions such as the ones above should check that their arguments are of the correct type and signal a type error if they are not. But there is always a price to pay for argument checking: it consumes machine cycles in every call to a function in order to weed out erroneous code.

Allegro CL has two sequence function modules: :safeseq and :fastseq. Either two can be require'd at any time, and they each cancel the effect of the other. These modules hold the safe or fast run-time definitions of several problematic sequence functions that are hard to decide how to balance between safety and speed.

Thus, to use safe sequence functions, evaluate at any time:

(require :safeseq)

And to use fast (but without argument checking) sequence functions, evaluate at any time:

(require :fastseq)

It should be noted that functions in the :safeseq module are not better per se than those in :fastseq, and for correct code each module's functions operate correctly. Rather, the functions in :safeseq behave better with improper arguments.

The current list of functions which are affected by these modules include (but are not limited to, possibly by indirection): elt, length, make-list, mapc, mapcar, mapcon, mapl, butlast, and nbutlast.

In development images, the module loaded by default in :safeseq. In production images (when the runtime argument to generate-application is non-nil), the default is :fastseq.

Copyright (c) 1998-2022, Franz Inc. Lafayette, CA., USA. All rights reserved.
This page was not revised from the 10.0 page.
Created 2019.8.20.

Allegro CL version 10.1
Unrevised from 10.0 to 10.1.
10.0 version