Stc-generated messages are of the form:
file.st, line n: msgType: some textwhereas 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)
Error: redefinition of 'foo' in instvar list
here, the name ``x'' occurs twice.Foo subclass:#Bar instanceVariableNames:'... x ... x ...' ...
Error: redefinition of 'foo' in arg/var list
here, the name ``arg1'' occurs twice.methodWith:arg1 with:arg2 with:arg1
Error: instvar 'foo' is already defined in a superclass
here, the superclassPoint subclass:#MyPoint instanceVariableNames:'... x ...' ...
Pointalready 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
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
Error: 'foo' is not lowercase
Error: subclasses of Foo not allowed
Error: Foo is a builtIn class
Behaviorand 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
Error: '!' must be duplicated (in string constant)
Error: '!' must be duplicated (in character constant)
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
whilemessage 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
#to:by:do:constructs, iff the receivers type is known or can be tracked.
You can force these methods to be executed by:
[ ... ] perform:#'whileTrue:' with:[ .... ]
Error: body of ifTrue/ifFalse: must be a Block
Error: body of whileTrue:/whileFalse: may not have args
Error: body of ifTrue:/ifFalse: may not have args
Error: undefined outcome of if
Error: cannot compile largeInteger literals yet (...)
myVar := LargeInteger readFromString:'..........'
Error: cannot compile if for value
This bug will be fixed in an upcoming version.foo := expression ifTrue:[expr1] ifFalse:[expr2].
expression ifTrue:[foo := expr1] ifFalse:[foo := expr2].
Warning: useless computation of constant (nil)
This warning is somewhat questionable: it is reported for totally correct code.foo ifTrue: ifFalse:[....]
Warning: constant 1 in multiplication
#*for non-numbers, and do nothing for
Warning: constant 0 in multiplication
#*for non-numbers, and evaluate to the constant 0 for
Warning: assignment to global variable 'FooBar'
Warning: declared 'Foo' as global
somewhere at the beginning of the file.Smalltalk at:#Foo put:nil
Warning: method var 'foo' hides instvar
Warning: block arg 'foo' hides instvar
Warning: block arg 'foo' hides method local
Warning: local 'foo' used before set
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
Warning: local 'foo' is never used
Warning: classvariable 'foo' is never used
Warning: thisContext is unsafe in inlined blocks
thisContextis 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.
You can avoid the ambiguity, by assigning
thisContext to a local
method variable outside the block (i.e. in the method), and use this
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
Warning: possible typing error:'fooBar'
fooBar, which looks very obscure to stc.
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
"/). 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:
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.
Alternatively, you can give additional command line arguments which
suppress these messages right from the start:
Finally, these can be enabled/disabled in the launcher's 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
which specifies the part within the VM, where the message was generated,
and a severity indicator (one of
The subsystems are:
IMG: image <filename> is not compatible with executable (not yet supported)
"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
This may change in one of the future versions.
IMG [error]: version-mismatch: className->superclassname
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
[XWorkstation]: cannot connect to Display
- check $DISPLAY
- try the unix command: "xhost +myHostName"
- check if the Xserver is running (if display is on a remote machine)
VM: doesNotUnderstand notUnderstood
#doesNotUnderstand:message. This error also raises the
|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
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)
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 (...)
MEM: Allocate n bytes more oldspace ...
MEM: ... done
ObjectMemory moreOldSpace:") or decided by itself (when free memory drops below some limit) to allocate more memory for oldSpace objects.
GC: found: n bytes of free storage (n:x max:y joins:z)
IGC: found: n bytes of free storage (n:x max:y joins:z)
MEM: very bad space conditions
Smalltalk cannot do much about this; however, a lowSpace interrupt
is triggered, which sends a
#lowSpaceCleanup message to
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 ;-).
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
Too many globals in method
superclass is (currently ?) nil
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
assignment to self | super | thisContext
assignment to true|false
Smalltalk at:#true put:something
These messages can be suppressed with:
or via the launcher's settings-messages menu.
[Image]: ... is not existing or not readable
[Image]: allocating n colors ...
[XWorkstation]: x-error cought maj=... min=... resource=...
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.
Fontconfig warning: ignoring UTF-8: not a valid region tag
LC_CTYPEshell 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").
"doc/coding/Signal-xxx"for how this is done.
Notice, that you can handle all related child signals in one handler, by catching the common parent signal. For example,
Object » errorSignalis the common parent of all other signals - handling this one will also handle all others.
Copyright © 1995 Claus Gittinger Development & Consulting