prev back next

Error & warning messages

Overview & contents

This document lists some (most?) of the error and warning messages from various parts of the system. A short explanation of what the message means, and what should be done is given for each.

Diagnostics produced by stc

When compiling with stc, error and warning messages may be either produced by stc itself, or by the c-compiler, during the second phase.
Remember: stc first creates C-code as intermediate code, and calls the c compiler for machine code generation.

Stc-generated messages are of the form:

file.st, line n: msgType: some text

while messages produced by the C-compiler usually look like:

file.c, line n: msgType: some text

(of course, the details depend on the type of c-compiler used, so no more information can be given here).

There should normally be no error messages from the C-compiler, except in wrong defined primitive code. However, some C-compilers are more 'picky' than others and output warnings sometimes. These can usually be ignored (and stc will be fixed to output code which does not produce warnings).

The handling of some errors can be changed by stc command line arguments. Also, warning messages may be disabled. See the stc manual page for more info.

Stc error messages


Error: redefinition of 'foo' (line n)
is reported, when a method for the same selector was already defined previously. The line number n tells the position of the previous method definition.
repair:
check the code and rename/remove the method.

Error: redefinition of 'foo' in instvar list
is reported, when the same identifier occurs twice in the instanceVariableNames list of a class.
I.e. if you try to define some class as:
    Foo subclass:#Bar
	instanceVariableNames:'... x ... x ...'
	  ...
here, the name x occurs twice.
repair:
check the definition and rename/remove the instance variable.

Error: redefinition of 'foo' in arg/var list
is reported, when the same identifier occurs twice in an argument list of a method or block.
I.e. if you try to define some method as:
	    methodWith:arg1 with:arg2 with:arg1
here, the name arg1 occurs twice.
repair:
rename the argument.

Error: instvar 'foo' is already defined in a superclass
is reported when an instance variable with the same name is already defined in a superclass.
I.e. if you define a class such as:
    Point subclass:#MyPoint
	  instanceVariableNames:'... x ...'
	  ...
here, the superclass Point already defined an instance variable named x.
repair:
rename/remove the instance variable.

In special situations (you do not want to change the source), turn off the error with the -errorInstVarRedef command line argument. This tells stc to output a warning only, and continue compilation.
The resulting code will access the new instance variable in the subclass (and classes derived from these). The superclass continues to access its original instance variable - of course.

Notice:
do not use this command line argument in general - it will lead to a sloppy coding style and may lead to unexpected behavior in your classes.

Error: global 'foo' is not uppercase
is reported, when no variable foo was defined. For identifiers starting with an uppercase character, these undefined names are automatically taken to be global.
For others, this error is reported.
repair:
add the missing definition (instance variable or local variable)
or:
change the name (to uppercase, if its meant to be a global)
Notice:
it is considered bad style (but not strictly an error) to use lowercase names for globals and/or class variables. However, for compatibility (i.e. when porting code from other smalltalks) it is possible to turn this error into a warning with the -errorLowerGlobal compiler switch.

Error: 'foo' is not lowercase
is reported when an instance variables, method/block locals or arguments name is starting with an upper case character. This is not strictly an error, but considered bas style. For compatibility (i.e. when porting code from other smalltalks) you can turn this error into a warning with the -errorUpperLocal command line argument.

Error: cannot compile largeInteger literals yet (...)
this is a limitation of the current stc - it cannot create largeInteger literals.
repair:
use a classVariable for your large-constants, and set them in the classes initialize method using:
	myVar := LargeInteger readFromString:'..........'
Note:
this is not a bug of yours, but a limitation of stc. It will be fixed in an upcoming version.

Error: block at line n or parenthesis nesting in foo
either a blocks bracket-nesting or expressions parenthesis nesting is wrong.
repair:
usually some bracket '[' or ']' or parenthesis '(' or ')' is missing

Error: '!' must be duplicated (in string constant)
Error: '!' must be duplicated (in character constant)
since the input to stc is standard fileIn source format, individual methods must be separated by '!'-characters, and '!'-characters within methods must be doubled. This also applies to exclamation marks in strings and character constants.
repair:
replace the single '!' by a double '!!'
Note: this applies only to files edited with the fileBrowser or other editor. Do NOT double '!'-characters when entering code into the systemBrowser.


*** incomplete: more to come here ***

Stc warning messagess


Warning: useless computation of constant (nil)
is output when an expression which evaluates to nil is detected, where the value is not used/needed. Typically, this is warning occurs with empty blocks as in:
   foo ifTrue:[] ifFalse:[....]
This warning is somewhat questionable: it is reported for totally correct code.
However, in some situations, it may make sense to look into the code and check for commented out code which should not be.

Warning: constant 1 in multiplication
stc generates code, which will perform the send of * for non-numbers, and do nothing for Integer and Float receivers.
You may want to have a look at the code to see if this multiplication is really needed.

Warning: constant 0 in multiplication
stc generates code, which will perform the send of * for non-numbers, and evaluate to the constant 0 for Integer and Float receivers.

Warning: assignment to global variable 'FooBar'
is output whenever a global is assigned to. In Smalltalk, it is considered bad coding style to heavily use global variables - you should always think twice before doing so. Usually a class variable will give you the same functionality AND provide a better encapsulation (and also security, since assignments/modifications can be trivially cought by limiting access through a class method, while globals can be accessed and modified from everywhere).
This warning can be turned off with the -warnGlobalAssign flag.

Warning: declared 'Foo' as global
is output, when some variable has been declared as global by stc. This is done, whenever an otherwise undeclared name, which starts with an upper case alpha character is encountered. You may want to check, if this is the intention, since typing errors in a class variables name may lead to this.
If its really a global variable that is intented, you should declare it before using it, by adding a line such as:
		Smalltalk at:Foo put:nil
somewhere at the beginning of the file.

Warning: method var 'foo' hides instvar
Warning: block arg 'foo' hides instvar
whenever a method variable/block arg is locally defined, which has the same name as an instance variable.
This warning is output to remind you, that the instance variable is not reachable in this inner scope - which may or may not be the intent.

Warning: block arg 'foo' hides method local
whenever a block arg is locally defined, which has the same name as a method variable.
This warning is output to remind you, that the method variable is not reachable in this inner scope - which may or may not be the intent.

Warning: local 'foo' used before set
This may or may not be really an error - since the language definition states that local variables are initialized to nil, it is perfectly legal to depend on this (for example, to check for the first run through a loop).

Warning: local 'foo' is always unassigned
A local variable is used, but never gets a value assigned. This is usually an error. However, it conforms to the language definition, therefore only a warning message is generated.

Warning: local 'foo' is never used
Warning: classvariable 'foo' is never used
an unused variable - the warning can usually be ignored, or the variables definition be removed.
In case of a classvariable, you should make sure that the variable is not used in subclasses before removing it (or move it to where it is supposed to be defined).

Warning: thisContext is unsafe in inlined blocks
A thisContext is encountered in a block, which is inlined; therefore thisContext will not return the blocks context, but instead the context of the enclosing block or method.
Stc may be changed in the future to either not inlining such blocks, or create a dummy context for the inlined block.

You can avoid the ambiguity, by assigning thisContext to a local method variable outside the block (i.e. in the method), and use this local instead.
In general, to avoid compatibility problems with other smalltalk implementations, it is wise to not use thisContext in blocks.


Warning: possible typing error:'fooBar'
you have used a selector fooBar, which looks very obscure to stc.
Although the program is syntactically correct, you should check if the selector is really what you intented.

Warning: end-of-line comments are a special ST/X feature
you have used the non portable end-of-line comment ("/). If you ever plan to transport the source code to another Smalltalk implementation, the code has to be changed.

Diagnostics produced by the runtime system

Startup messages


image is not compatible with executable (not yet supported)
the snapshot file (default: "st.img") was written by an earlier version of the ST/X executable; i.e. smalltalk has been recompiled or relinked in the meantime.
The state contained in the file cannot be restored. Future versions of ST/X may convert the image and be able to read the image, even in this case. For now, ST/X performs the normal (clean-) startup.
Warning:
currently, old images are unusable, if ST/X is recompiled/ relinked. Make certain, that all of your classes have been filedOut before you recreate a smalltalk executable. This may change in one of the future versions.

version-mismatch: className->superclassname
the classes superclass definition does not match. This occurs when a superclass has been changed (for example: instance variables have been added or removed) and compiled (with stc), and the subclass has NOT been recompiled.

Usually, ST/X cannot work correctly in this situation - you will almost certainly run into the debugger, get memory manager errors and/or even get a core dump later, since the class will get invalid data when accessing instance variables and access illegal memory, when modifying instance variables.

repair:
recompile the class (and/or superclass) & relink ST/X

cannot connect to Display
You should either set the DISPLAY shell-variable correctly or make certain, that the X-server defined by DISPLAY permits connections. (actually not a VM message, but produced by the Workstation class)
repair:
- check $DISPLAY
- try the unix command: "xhost +myHostName"
- check if the Xserver is running (if display is on a remote machine)

Memory management errors


findRefs: alien xxxxxxxx space x in yyyyyyy space x offset x ()
the garbage collector found an invalid object reference to a non-object or invalid object x in the object y which is an instance of aClass.
This error should normally not happen and is usually worth a bug report. However, ST/X's memory manager is relatively robust against these errors - in most cases, execution can still continue.
Sources of this error:
- version-mismatch (see above)
- errors in primitive code clobbering objects
- unprotected objectpointers kept in external c-code or globals
- implementation bug in the VM (send a bug report)

Incremental compiler messages & popups


Too many literals in method
Incremental compiled code sets a limitation of 2^16 (65637) literals per method.
Notice:
You hardly reach this limit.

Too many globals in method
Incremental compiled code sets a limitation of 255 references to globals per method.
Notice:
You hardly reach this limit.

superclass is (currently ?) nil
A supersend in a class which has currently no superclass. The Smalltalk language does not specify the result of a supersend, if there is no superclass. In ST/X, it will be handled like a normal (non-super) message send.

This is a warning (not treated as an error), since the superclass could be non-nil at runtime. Notice, that no additional runtime checks for this situation are performed by the VM, since this would involve additional overhead, while in practice this situation is very rare.


assignment to a constant
assignment to nil
an obvious error

assignment to self | super | thisContext
assignments to these pseudo-variables is not allowed.

assignment to true|false
since assigning new values to these variables will make the whole system unusable, the compiler flags this as an error. If you are really willing crash the system this way, try Smalltalk at:#true put:something
- but please: save your work before doing so ....

*** incomplete: more to come ***

Misc messages from various classes

*** incomplete: more to come ***

Runtime errors

Most runtime errors will raise a signal, which can be cought or handled in an exception handler. See the documentation on exceptions and/or read and understand the sample code in "doc/coding/Signal-xxx" for how this is done.
The following table lists (most) signals, where they are defined and when they are typically raised.
Notice, that you can handle all related child signals in one handler, by catching the common parent signal. For example, Object>>errorSignal is the common parent of all other signals - handling this one will also handle all others.

List of signals raised on errors

  signal                        in class        raised if

ErrorSignal Object any error not in list below or #error: This is the parent of all others. HaltSignal Object sent by #halt MessageNotUnderStoodSignal Object no method for selector in a send UserInterruptSignal Object CNTL-C was pressed RecursionInterruptSignal Object too much recursion (stack limit reached) ExceptionInterruptSignal Object graphic display error SubscriptOutOfBoundsSignal Object subscript not within 1..size NonIntegerIndexSignal Object subscript is not integer NotFoundSignal Object element was not found in a collection KeyNotFoundSignal Object key was not found in a collection ElementOutOfBoundsSignal Object element is not appropriate for collection InformationSignal Object PrimitiveFailureSignal Object error in primitive code AbortSignal Object (*) abort from debugger OSSignals Object raised on unix-signal TerminationSignal Process for soft termination of a process PrivateMethodSignal Method tried to execute a private method InvalidCodeSignal Method/Block any execution error not below Also the parent of those. NoByteCodeSignal Method/Block bytecode is nil InvalidByteCodeSignal Method/Block bytecode is not a ByteArray InvalidInstructionSignal Method/Block invalid instruction in bytecode BadLiteralsSignal Method/Block literal array is not an Array NonBooleanReceiverSignal Method/Block receiver of ifTrue/ifFalse is not a boolean ArgumentSignal Method/Block something wrong with argument(s) ArithmeticSignal ArithmeticValue not directly raised. parent of all below. DivisionByZeroSignal ArithmeticValue a division by zero was attempted DomainErrorSignal ArithmeticValue value is out of domain for math-function (mainly with Floats) OverflowSignal ArithmeticValue overflow in arithmetic operation (mainly with Floats; not supported on all platforms) UnderflowSignal ArithmeticValue underflow in arithmetic operation (mainly with Floats; not supported on all platforms) AllocationFailureSignal ObjectMemory memory allocation failed BreakpointSignal MessageTracer breakpoint hit InvalidNewSignal Block attempt to create a block with #new InvalidKeySignal Collection key is not of appropriate type BrokenPipeSignal PipeStream read from a pipe or socket with no one writing ErrorDuringFileInSignal PositionableStream an error occured while filing in code NoHandlerSignal Signal an unhandled signal raise occured (*) not raised if unhandled


Copyright © Claus Gittinger Development & Consulting, all rights reserved

(cg@ssw.de)