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 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.
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.
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:here, the name ``x'' occurs twice.
Foo subclass:#Bar instanceVariableNames:'... x ... x ...' ...
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:here, the name ``arg1'' occurs twice.
methodWith:arg1 with:arg2 with:arg1
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:here, the superclass
Point subclass:#MyPoint instanceVariableNames:'... x ...' ...Point
already defined an instance variable named ``x''.
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.
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.
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: subclasses of Foo not allowed
this applies the classesSmallInteger
,UndefinedObject
,True
andFalse
.
For implementation reasons, you cannot create subclasses of these (neither with stc nor with the browser.
Error: Foo is a builtIn class
Among others, this applies to the classesObject
,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).
Error: block at line n or parenthesis nesting in foo
either a blocks bracket-nesting or expressions parenthesis nesting is wrong.
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.
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.
"-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.
#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.
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.
Error: cannot compile largeInteger literals yet (...)
this is a limitation of the current stc - it cannot create largeInteger literals.
initialize
method using:
myVar := LargeInteger readFromString:'..........'
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.
expression ifTrue:[foo := expr1]
ifFalse:[foo := expr2].
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:This warning is somewhat questionable: it is reported for totally correct code.
foo ifTrue:[] ifFalse:[....]
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 forInteger
andFloat
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 forInteger
andFloat
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:somewhere at the beginning of the file.
Smalltalk at:#Foo put:nil
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
AthisContext
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 usethisContext
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 selectorfooBar
, 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 likeifTrue: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.
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:
for the error messages, and:
Smalltalk debugPrinting:false
for the informal messages. You may place the above expressions into
any of your startup files, or evaluate them at any time in a workspace.
Smalltalk infoPrinting:false
Alternatively, you can give additional command line arguments which
suppress these messages right from the start:
Finally, these can be enabled/disabled in the launchers settings-messages menu.
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:
IMG: image <filename> is not compatible with executable (not yet supported)
the snapshot file (default:Warning:"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.
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.
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.repair: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.
recompile the class (and/or superclass) & relink ST/X
[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)
VM: doesNotUnderstand notUnderstood
some object does not understand the#doesNotUnderstand:
message. This error also raises theInternalError
exception.
#doesNotUnderstand:
.
|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.
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 exeption 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.
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.
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 ;-).
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).
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).
Too many globals in method
Incremental compiled code sets a limitation of 255 references to distinct global or class variables per method.
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 ....
These messages can be suppressed with:
Object infoPrinting:false
or via the launchers settings-messages menu.
[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.
"doc/coding/Signal-xxx"
for how this is done.
The following table lists (most) signals, where they are defined,
and in which situation they are typically raised.
The list below may not be complete - there are still error situations
in which only a general error is reported (instead of a specific signal).
Most programmers are not affected by this, however, there may be situations
where a single specific error has to be handled.
In practice, these situations are rare and for most applications it is
suffucient to handle the parent (Object>>ErrorSignal
) in one handler.
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.
signal in class raised if*** this list may be incomplete, as newer systems may add more signals ***
ErrorSignal Object any error not listed below. Also raised by the #error: method. This is the parent of all others. HaltSignal Object raised by the #halt method . MessageNotUnderStoodSignal Object no method for selector in a send. raised by the #doesNotUnderstand: method. UserInterruptSignal Object Ctrl-C was pressed RecursionInterruptSignal Object too much recursion (stack limit reached) A handler can increase the stack limit and continue execution. The stack limit can be changed by the program or via command line arguments. ExceptionInterruptSignal Object graphic display error. This is raised as a consequence of X Error reports. SubscriptOutOfBoundsSignal Object a subscript is not within 1..size (for example in an indexed array access) NonIntegerIndexSignal Object subscript is not integer (for example in an indexed array access) NotFoundSignal Object an element was not found in a collection KeyNotFoundSignal Object a key was not found in a collection ElementOutOfBoundsSignal Object element is not appropriate for collection (for example when storing non-characters into a string) DeepCopyErrorSignal Object invalid request for deepCopy * InformationSignal Object if handled, this is raised by the #information: method passing the info string. Allows info-boxes to be suppressed. * WarningSignal Object if handled, this is raised by the #warn: method passing the info string. Allows info-boxes to be suppressed. UserNotificationSignal Object parent of InformationSignal and WarningSignal. Allows info- and warnboxes to be suppressed by a common handler. * ActivityNotificationSignal Object request to display information about activity (to be displayed in a topViews title or info area) PrimitiveFailureSignal Object error in primitive code. The reason for raising this signal vary with the method; typically, this occurs when invalid arguments are passed to primitive code. * AbortSignal Object abort from debugger. This signal is special in that it is not raised for error conditions, but to leave some action and return to a save place. All views handle this signal in their event dispatching loop. OSSignals Object raised on unix-signal. To have a unix signal be reported as a smalltalk signal, the unix signal has to be first enabled, and then be bound to a signal object. InvalidKeySignal Collection access with invalid key. Typically, this is raised if nil is used as key in a set or dictionary. EmptyCollectionSignal Collection remove from an empty collection NotEnoughElementsSignal Collection too small of a collection ValueNotFoundSignal Collection a value was not found ColorAllocationFailSignal Color color allocation failed (while allocation fix colors) * CurrentScreenQuerySignal Display query for the current screen DeviceErrorSignal Display any display error TerminationSignal Process for soft termination of a process. Programs may handle this for cleanup (or to disallow termination) ExecutionErrorSignal Code parent of all execution errors 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). Raised if a blocks number of actual arguments does not match the number of formal arguments. Or, if a methids number of arguments is wrong in a #perform; or if the argument of a #performWithArgs: is not an array. CompilationFailedSignal LazyMethod a method could not be compiled when first executed InvalidReturnSignal Context return from a context which has already returned. 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. This signal is raised when either an object creation request or some buffer request (i.e. malloc) failed. If a handler exists, and it continues execution, a nil value will be returned from the object creation request. BreakpointSignal MessageTracer breakpoint hit InvalidNewSignal Block attempt to create a block with #new StreamErrorSignal Stream any stream error (parent of the others) EndOfStreamSignal Stream i/o past the end attempted PositionErrorSignal Stream invalid position ReadErrorSignal Stream read eror WriteErrorSignal Stream write error BrokenPipeSignal PipeStream read from a pipe or socket with no one writing ErrorDuringFileInSignal PositionableStream an error occured while filing in code. InvalidModeSignal ExternalStream binary i/o in textmode or vice versa InvalidOperationSignal ExternalStream an unsupported operation was attempted InvalidReadSignal ExternalStream reading is not supported InvalidWriteSignal ExternalStream writing is not supported OpenErrorSignal ExternalStream file/stream opening failed StreamNotOpenSignal ExternalStram i/o attempt with a closed stream * ImageNotFoundQuerySignal Image raised if a bitmap-image could not be loaded from a file. BreakpointSignal MessageTracer used for breakpointing FileOutErrorSignal Class an error occured while filing out code * CreateNameSpaceQuerySignal Class to ask if a new namespace should be created without user confirmation. (for example: during fileIn) MethodRedefinitionSignal Class raised, if an existing method is redefined in another package (if catchMethodRedefinition is enabled) * NameSpaceQuerySignal Class to ask for the nameSpace, into which new classes are to be installed. * PackageQuerySignal Class to ask for a package identifier for new classes and methods. * UpdateChangeFileQuerySignal Class to ask if the changeFile should be updated * UsedNameSpaceQuerySignal Class to ask for a collection of namespaces, from which names are to be resolved AutoloadFailedSignal Autoload a class could not be autoloaded AccessDeniedErrorSignal OperatingSystem access to some system resource was denied (no permission) FileNotFoundErrorSignal OperatingSystem some file was not found CompilationFailedSignal LazyMethod compilation of a lazy method failed NoHandlerSignal Signal an unhandled signal raise occured. If not handled by the application, this signal is always handled by a default handler, which opens a debugger on the failing process. RecursiveExceptionSignal Exception recursive signal raise in an exception handler. This is raised if the same exception occurs again in a signals exception handler, and no other handler for this exception was found. RestartSignal Process forces a process to restart TerminateSignal Process forces a process to (soft-) terminate BinaryLoadErrorSignal BinaryStorage parent of all binaryLoad errors. Also raised if a format error occurs. NonexistingClassSignal BinaryStorage attempt to load an object for which there is no class available. InvalidClassSignal BinaryStorage attempt to load an object for which there is no compatible class available Parent of below. ChangedInstLayoutSignal BinaryStorage the class has a different instance layout than the to be loaded objects class. (i.e. instance variables are not at the same position(s)) ChangedInstSizeSignal BinaryStorage the class has a different number of instance variables w.r.t. the loaded objects class. ChangedIndexedInstSignal BinaryStorage the class has indexed instance variables, while the loaded object has not; or vice versa. * RequestConversionSignal BinaryStorage raised to request a conversion of an incompatible object. * LastEventQuerySignal WindowGroup to ask for the last event LeaveSignal WindowGroup to ask for the eventLoop to be left * WindowGroupQuerySignal WindowGroup to ask for the current windowGroup (*) queries - no debugger/emergency if unhandled
Copyright © 1995 Claus Gittinger Development & Consulting
<cg@exept.de>