Error & Warning Messages

Overview & Contents

• Diagnostics produced by the stc compiler
  • stc error messages
    • variables
    • classes
    • syntax
    • checked semantic
    • limitations
  • stc warning messages

• Diagnostics produced by the runtime system
  • Startup messages
  • Message lookup errors
  • Memory management errors
  • Memory management diagnostics
  • Other VM errors
  • Incremental compiler messages & popups
  • Misc messages from various classes
  • Misc messages from non-Smalltalk library code

• Runtime errors (exceptions)

Diagnostics produced by stc

Stc-generated messages are of the form:

file.st, line n: msgType: some text

file.c, line n: msgType: some text

There should 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

variables

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

  • hint:
    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.
    However, there is one situation where allowing instvar redefinitions makes sense and is very useful: if you port a class from another smalltalk system.

    For example: if a subclass of View is to be brought to ST/X from ST-80, this may result in instvar redefinitions, since the inherited instance variables are certainly different in those class hierarchies and conflicts are possible (although not likely).
    Since the conflicting instvar was not present in the original hierarchy, all references to it from within the new class are certainly meant for its own instance variable - not to the inherited one. Thus the semantic of accessing the own instvar is certainly the correct one for that class.

  • warning:
    This should be only only used for a quick port of class code. In the long run, classes should be rewritten to have distinct instvar names.

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

classes

• Error: subclasses of Foo not allowed
  this applies the classes SmallInteger, UndefinedObject, True and False.
  For implementation reasons, you cannot create subclasses of these (neither with stc nor with the browser.
  • repair:
    read the documentation on the language and the implementation

• Error: Foo is a builtIn class
  Among others, this applies to the classes Object, Method Block, Context, BlockContext, String, Symbol, Array, Behavior and all of their superclasses.

  The instance layout of those class is known by (and built into) the VM. You may not add or remove instance variables or change its layout (i.e. introduce/remove indexed variables).

  • repair:
    rethink about what you tried to do.

syntax

• Error: block at line n or parenthesis nesting in foo
  either a blocks bracket-nesting or expressions parenthesis nesting is wrong.
  • repair:
    typically 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 '!!'

  • notice:
    this only applies to files edited with the fileBrowser or other editor.
    Do NOT double '!'-characters when entering code into the systemBrowser, since all fileIn/fileOut operations double/undouble exclamation marks automatically.

checked semantic

Some of these checks can be turned of by stc command line arguments, which will force it to generate code even for suspect constructs.

• Error: body of whileTrue/whileFalse: must be a Block
  the argument to a while message is known to be not a block. The compiler can (of course) not figure out all situations, in which this will happen at runtime. It is only reported for constant (non-block) arguments, or if stc's type tracker can definitely assert a variables type to be a nonBlock.
  • repair:
    usually some bracket '[' or ']' is missing, or a typing error (round parentesis instead of brackets).

  • notice:
    Unless the "-optControl" command line option is given, stc generates inline code for #whileXXX, #ifXXX, #timesRepeat, #to:do: and #to:by:do: constructs, iff the receivers type is known or can be tracked.
    No real message send operation is performed at runtime for those.
    This means that redefining the corresponding methods (in the Block-class) has no effect on program execution, except for explicit #perform: sends.

    You can force these methods to be executed by:

        [ ... ] perform:#'whileTrue:' with:[ .... ]
    

• Error: body of ifTrue/ifFalse: must be a Block
  like above.

• Error: body of whileTrue:/whileFalse: may not have args
  an obvious error - the blocks in while-messages are evaluated without an argument.
  • repair:
    remove the formal block args - or check if a while-loop is really your intent.

• Error: body of ifTrue:/ifFalse: may not have args
  like above

• Error: undefined outcome of if
  the receiver of an if-type message is known to be not a boolean.

limitations

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

  • late note:
    this bug has been fixed with release 2.10.7.

• Error: cannot compile if for value
  this is a bug in the current stc implementation: it cannot always compile constructs like:

  foo := expression ifTrue:[expr1] ifFalse:[expr2].

  This bug will be fixed in an upcoming version.
  • repair:
    replace by:

    	expression ifTrue:[foo := expr1]
    		   ifFalse:[foo := expr2].
    

  • note:
    this is not a bug of yours, but a limitation of stc. It will be fixed in an upcoming version.

  • late note:
    with release 2.10.7 this has been fixed mostly. However, in rare situations (complicated expressions in the if-blocks), this may still be occur.

• *** this list may be incomplete, as newer versions may add more messages ***

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: if/while with unassigned receiver
  A variable is used in an if or while expression, but that variable never gets a value assigned (i.e. is known to be nil).

• 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.
  The set of obscure selectors has been determined by heuristics, by statistics over common bugs. Things like ifTrue:ifTrue: are among them. It is probably not complete, and more common typing errors are to be checked for.

• 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

Normally, you would not care for these messages, except if ST/X's output is piped to another program. In this case, you may want to suppress these messages.
(future versions will allow these to be written into a logfile as option)

Most debug & error messages can be suppressed by evaluating:

	Smalltalk debugPrinting:false

	Smalltalk infoPrinting:false

Alternatively, you can give additional command line arguments which suppress these messages right from the start:

	smalltalk -noDebugPrint -noInfoPrint

Messages for very severe errors (crashes) cannot be suppressed.

Starting with ST/X release 3, all system messages are prefixed by a subsystem name (such as "IRQ" or "MEM"), which specifies the part within the VM, where the message was generated, and a severity indicator (one of "error", "warning" or "info").
The subsystems are:

IRQ

the interrupt subsystem which handles the timer, user interrupts (CTRL-C), I/O interrupts and memory access violations.

MEM

memory management

IGC

incremental garbage collector (within the memory system)

GC

blocking (mark & sweep) garbage collector (within the memory system)

CGC

compressing garbage collector (within the memory system)

IMG

snapshot image save & reload subsystem

VM

other message

Startup messages

• IMG: image <filename> 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), or by a system running on a different processor architecture;

  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, ignoring the image.

  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.

  This message cannot be suppressed.

• IMG [error]: 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.

  If this happens, the bad class and all of its subclasses are ignored by the system and will not be present (i.e. the system will initialize as if those classes were not present).

  Usually, ST/X cannot work correctly in this situation - you will almost certainly run into the debugger due to doesNotUnderstand errors. repair:

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

  This message cannot be suppressed.

• [XWorkstation]: 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 this is 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)

Message lookup errors

• VM: doesNotUnderstand notUnderstood
  some object does not understand the #doesNotUnderstand: message. This error also raises the InternalError exception.

  Sources of this error:

  - corrupted superclass chain
  - invalid class-entry in an object
  - implementation bug in the VM (send a bug report)

  There are some situations, where this error may occur due to a programmers fault. For example, if you create an instance of a new anonymous class, send it any unimplemented message AND that class does not implement a method for #doesNotUnderstand:.
  i.e.

      |newClass|
  
      newClass := (Metaclass new) new.
      newClass setSuperclass:nil.
      newClass new foo
  

  If you create a nil-subclass in the browser (i.e. not 'manually'), the class will always include a default implementation for #doesNotUnderstand: to prevent this kind of error.

• VM: searchclass is not a behavior
• VM: selector array is not an array
• VM: method array is not an array
• VM: nil method array
• VM: selector/method array sizes don't match
• VM: superclass chain seems endless in lookup

  these are various messages produced by corrupted classes. These should only occur if you manually manipulated a classes instance variables - otherwise, send a bug report.

  Sources of these errors:

  as above

  Notice:

  Portable applications should not depend on these error conditions to be handled gracefully - some other smalltalk implementation may simply dump core if one of the above errors occurs.

Memory management errors

• MEM: findRefs: alien xxxxxxxx in yyyyyyy offset x (aClass)
  the garbage collector found an invalid object reference to a non-object or free 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 (except if its due to bad primitive code as described below).
  However, ST/X's memory manager is relatively robust against these errors - in most cases, execution can still continue (for a while).
  One exception is when this error happens in the incremental GC; continuing will probably lead to more errors of this kind. You should terminate the incremental GC process.

  In any case, you should try to save as much of your work as possible (by filing out your classes) and restart the system from your last saved image. You can try to write a new image; there are some repair mechanisms built in, which nil out illegal references. If the wrong pointer was caused by a bad primitive or external C subsystem, chances are good that the system may continue to work. However, do not overwrite your last image and do not overwrite existing source files (i.e. write a new image, and fileOut into a different directory) because you cannot be certain that the incore source information is still valid and consistent.

  Sources of this error:

  - version-mismatch (see above)
  - errors in primitive code clobbering objects
  - unprotected objectpointers kept in external c-code or globals
  - malloc'ing ST-objects in a primitive (which is not allowed)
  - freeing ST-objects in a primitive
  - implementation bug in the VM (send a bug report)

• GC: tried to mark free inst xxxx in yyyy(n) space s class:zzzz (...)
  the garbage collector found a reference to an object which was freed in a previous GC cycle. This error should not happen as is usually worth a bug report (except if its due to bad primitive code as described below).
  The collector nils this invalid reference in order to protect itself from further trouble. However, this may lead to more strange behavior in your program.

  Sources of this error:

  - typically, this error results from an ommitted __STORE-macro in primitive code. This macros tells the collector, that a reference has been created (usually to some newly created object) and enters the destination into the remembered lists. If that macro is missing, the gc may consider the object as free, although a reference to it exists, and find this situation in the next GC cycle.

Memory management diagnostics

• MEM: Allocate n bytes more oldspace ...
MEM: ... done
  the memory system was either forced to (via "ObjectMemory moreOldSpace:") or decided by itself (when free memory drops below some limit) to allocate more memory for oldSpace objects.
  Depending on the capabilities of your operating system, this may or may not be a timely operation;
  On all systems which allow arbitrary mmap'ing of memory pages (i.e. Linux, SGI, Suns, Unixware and some others), this operation takes a few milliseconds; on systems which do not support this (HP, Ultrix, RealIX and others), it may take seconds.

• GC: found: n bytes of free storage (n:x max:y joins:z)
  the blocking (i.e. non-incremental) garbage collector just finished its work and found n bytes of free storage.

• IGC: found: n bytes of free storage (n:x max:y joins:z)
  the incremental garbage collector just finished its work and found n bytes of free storage.

• MEM: very bad space conditions
  the object memory is full and the operatingSystem is not willing to hand out more memory in an allocation request. This occurs if the smalltalk process has reached its (VM) limits, or if the system is running out of swap/paging space.

  Smalltalk cannot do much about this; however, a lowSpace interrupt is triggered, which sends a #lowSpaceCleanup message to all classes.
  All classes which keep huge data (for example cached bitmap images or other reconstructable data) should implement a method for this message and release as much as possible there.
  In rare situations, this error occurs in a loop (if the cleanup did not release enough memory, and further allocation requests failed as well).
  In this case, you have to kill or otherwise terminate the smalltalk process manually (via the UNIX kill command). Then, either check your application for excessive memory requirements (endless loop when constructing some object hierarchy), or reconfigure your system to provide more swap space and restart from a saved image.

  Notice that some (bad) Unix systems simply kill the smalltalk process, so smalltalk gets no chance to perform the above cleanup actions or handle the error in a graceful way. Good systems return an error from the allocation (sbrk / mmap or malloc) request (this is a hint to OS designers ;-).

Other VM errors

• VM: sigsegv
  a segmentation violation (illegal memory access) occurred
  This error should normally not happen and is usually worth a bug report (if it occurs during normal ST/X operation, i.e. not caused by some external (C-language) subsystem or by a user supplied primitive). However, ST/X is relatively robust against these errors - in most cases, execution can still continue.

  To continue execution after this error, you have to abort NOT continue in the debugger - otherwise, the segmentation violation will occur over and over again (the reason lies in Unix's handling of the segv exception, retrying the illegal memory access).

Incremental compiler messages & popups

• Too many literals in method
  Incremental compiled code sets a limitation of 2^16 (65637) distinct literals per method. This includes all explicit constants (i.e. constant strings, float or largeInteger constants, symbols, array and byteArray constants) and literals as introduced by message sends (for the selector).

  Notice:

  You hardly reach this limit.

• Too many globals in method
  Incremental compiled code sets a limitation of 255 references to distinct global or class variables 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
  these are obvious errors

• assignment to self | super | thisContext
  assignments to these pseudo-variables are not allowed/possible.

• assignment to true|false
  since assigning new values to these (pseudo-) variables will make the whole system unusable, the compiler flags this as an error. If you are really willing to crash the system this way, try

      Smalltalk at:#true put:something
  

  
  - but please: save your work before doing so ....

• *** this list may be incomplete, as newer versions may add more messages ***

Misc messages from various classes

These messages can be suppressed with:

Object infoPrinting:false

• [Image]: ... is not existing or not readable
  a bitmap image was not found by the Image class.

• [Image]: allocating n colors ...
  simply an information message - color allocation can be somewhat slow if no preallocated fixed color table is configured.

• [XWorkstation]: x-error cought maj=... min=... resource=...
  an error was reported from the display connection (X-server).

  These are often a consequence of some view not being destroyed correctly. In this case, the garbage collectors finalization procedure frees the view and all of its subviews, by sending destroy requests to the display server.
  However, those requests are ususally not sent in the views subview order, so that a superview may be destroyed before a subview. Since the server internally destroys all subviews with every superview destroy request, the subview-destroy request may be for such an already destroyed view and is reported by the server.

  Since the garbage collector has no idea of the view hierarchy, this annoying message is hard to suppress. As a programmer, you should always perform an explicit destroy on a topView when it is no longer in use. Be especially careful with popup boxes.

  This diagnostic is informal only - this is no error situation and does not crash or otherwise affect the system.

• *** this list may be incomplete, as newer versions may add more messages ***

Misc messages from non-Smalltalk library code

• Fontconfig warning: ignoring UTF-8: not a valid region tag
  This message is generated by the Xft font subsystem, iff the LC_CTYPE shell environment variable contains a value which is not a valid country/region tag. Under OSX, this typically happens when LC_CTYPE is set to "UTF-8", instead of "de.UTF-8" or "en.UTF-8". The message vanishes, if you change LC_CTYPE as appropriate (i.e. $LANG.UTF-8) in the calling shell (i.e. "export LC_CTYPE=de.UTF-8").

• *** this list may be incomplete, as newer versions may add more messages ***

Runtime errors (exceptions)

Copyright © 1995 Claus Gittinger, all rights reserved