Known bugs and inconveniences
This page lists known bugs and inconveniences, and workarounds if available.
Only bugs which are not severe, hard to fix or which only occur
when certain (unusual) situations arise are listed here
(other bugs will be fixed instead of documented ;-)
Sorry - this list may be incomplete - we just started to maintain it.
- Runtime system
- Dynamic Object loading
- Loading dynamic code for a method leads to a crash,
if that method is currently active
- Description:
STC-compiling a method which is currently been executed
(in another thread) leads to a crash.
- Failure reason:
The system does not check for this situation and possibly unloads
the old code from the memory. When the other thread is resumed,
it lost its code and a segmentation violation is usually triggered.
- restarting an image which contains dynamic code for individual methods
leads to a crash if that method is invoked before the ObjectFileLoader
has reloaded the dynamic modules.
- Description:
When individual methods are accepted which contain primitive code,
and an image is saved, those dlls are reloaded during the early image
restart phase. However, if any method which is required by this restart
code is in the set of dynamic modules, that method has no valid machine code
by the time its invoked.
This leads to a crash during that init phase.
Affected by this are mostly primitive methods of the Object, Array,
Number and OperatingSystem classes
(which are not subject to user-modifications, anyway).
- Failure reason:
The system does not check for this situation. It should use the
old methods code (as in the executable) during the initialization,
until the dynamic method has been reloaded and installed correctly.
- Workaround:
Recompile the whole class (using stc) and recreate (i.e. relink)
a new smalltalk executable.
- Deep stack unwinding
- Unwinding a very deep stack (for example, after a recursion exception)
may take very long, if those contexts have been accessed.
- Description:
When returning from a recursion exception, the unwind takes very long,
if contexts have been accessed in the debugger.
(i.e. if you looked into contexts high in the calling hierarchy,
or accepted any code from within the debugger).
- Failure reason:
The thread has to unwind its stack, which (due to a bad algorithm in the VM)
may take very long in certain situations (if many or all of them have been marked
as being potentially referenced).
However, the unwinding is done interruptably - therefore, higher priority
processes (or, if you enabled preemptive scheduling, same priority processes)
are not blocked.
- Status:
Open - a better algorithm in the VM will be implemented in one of the next
releases. This behavior is not fatal, since it is not encountered/noticed
in `normal' operation of the system.
- stc compiler
- Cascades
- some cascade expressions cause stc to generate C-code
which cannot be compiled by he c-compiler.
- Description:
Some stc versions generate syntactically wrong code for certain
cascade expressions.
- Workaround:
Simplify the cascade, by using a temporary variable.
- Status:
open.
- If as value with blocks
- ifTrue:/ifFalse: expressions fail to compile,
- Description:
Some ifTrue:/ifFalse: expressions fail to compile,
if the value of the if is used, and a block is generated in
one of the alternatives.
- Workaround:
Move the assignment into the alternative(s).
- Status:
open.
- String constants containing '??' (AIX only)
- string constants containing '??' where compiled wrong on AIX2.3
- Description:
The AIX C-compiler treats '??' as an escape sequence to translate the
followup character (for example, '??<' gets translated to '{'.
This (nonstandard) undocumented "feature" lead to bad translation
of some smalltalk string constants.
(such a sequence is often contained in packed bitmap strings).
- Status:
fixed with release 3.4.5.
- Very long String constants
- Very long string constants may lead to an stc compiler crash
- Failure reason:
Since stc is build using yacc & lex, certain limitations which are
inherit to those tools may lead to crashes. One of them is the lexers
internal buffer, which is fixed in size.
Although stc as delivered was built with an increased buffer (64k),
it is still fix in size and not dynamically grown in case of a long
regular expression match - especially, a long string- constant may
overflow this buffer.
Under normal situations, this limit is hardly ever reached, except if
inline-bitmap image descriptions (packed strings) as generated by the
imageEditor are compiled.
- Workaround:
Save your bitmap image to a file, and load it from that file during class
initialization.
Or, do not stc-compile these methods (the byteCode compiler is written in smalltalk
and does not suffer from this limitation).
- Status:
open
- Too much inlining
- not is always inlined - but always assuming that receiver is boolean (#not to non-boolean fails)
- Failure reason:
stc's inlining is too agressive with respect to the #not message; the non-boolean case is
never handled (instead, a non-boolean is treated like false).
- Workaround:
Do not use those messages on non-booleans.
Or, do not stc-compile these methods (the byteCode compiler/just in time compiler combination
handles these sends correctly)
Or, add the argument "-inlinenot" to the stc-options (in the Make.proto); this will turn off any inlining
of the #not message.
- Status:
open - should be fixed to use inline code for booleans, but perform a real send for non-booleans.
- Basic classes
- making a public class private
- does not recompile methods accessing the old (public) name
- Description:
'make private' does not recompile methods which access the class
under its public name.
- Workaround:
Find global refs to the old (public) className and re-accept them.
- View classes
- Menus & Shortcuts
- underline - access character position
- shortCut
- WINDOWS (Win-9x / Win-NT) graphics interface
- a views border is not correctly drawn
- only borderWidths of 0 and 1 are supported
- a bordered view leads to wrong clip in its parent view
- the borderColor is ignored
- not all lineStyles work properly under W95
- pixmap borders are not supported
- ViewBackground Pixmaps
- the viewOrigin is ignored when a viewBackground pixmap is drawn
- VGL interface
- VGL is not supported with Win-95 / Win-NT
- VGL gets sometimes confused if multiple GL views are drawing
simultaneously.
- Description:
Sometimes, the vogl library gets confused if multiple GL views
are active simultaneously. You get a bunch of 'vogl not initialized'
messages on the xterm window and one or more GL views fail to
perform any drawing operation.
This only happens with a vogl (GL simulation) system.
Systems with a real GL implementation (i.e. Silicon Graphics), this
error does not occur.
- Failure reason:
The vogl library is not perfectly thread save and some internal
state may be overwritten by the other GL view.
- Workaround:
- close the GL view and reopen it.
- only run one GL view at a time.
- Status:
Open - will not be fixed, since a switch to openGL is planned for
in the near future.
- Widget classes
- pullDown menu
- A large pullDown menu is clipped to the topViews bounds.
- Description:
A pullDownMenu with many items is clipped by the topViews bounds.
- Failure reason:
The pullDownMenu is created as a subView of the top window -
it should be a popUp view.
- Status:
Open - we are currently migrating to the new MenuPanel, which is
much more flexible (dynamic item enabling via valueHolders etc.) and
has already fixed this bug.
New applications should not use PullDownMenu - therefore, will not suffer
from that problem.
- Tools classes
- Browser related stuff
- Searching for senders seems to fail sometimes
- Description:
A search for senders returns wrong info, although you are
certain, that there are senders.
- Failure reason:
The search for senders looks at the methods literalTable to find
selectors quickly (instead of parsing the sourceCode).
This fails with autoloaded classes which have lazy compiler methods.
- Workaround:
- turn off lazy compilation
- use the string search in the browser
- Status:
Closed - correct behavior is only achieved by a loading all autoloaded classes.
This would make this search very slow.
Therefore, the behavior will not be changed.
- Newly created classCategories & method categories vanish,
if no class/method is created in it.
- Description:
When a class/method category is created, and no class/method
was created in it, that category is gone after switching to another
category.
- Failure reason:
ST/X keeps the category information as an instance variable in
the class/method object - not in a separate dictionary as done by
ST-80.
- Status:
Closed - this is not a bug - just a different behavior.
- HTML DocumentView related stuff
- HTML view blocked when restarting an image (with an open HTML viewer)
- Description:
The view blocks after if the displayed page contains images.
- Failure reason:
The documentview does not restart its image fetcher thread and
will sooner or later block, waiting for the shared queue.
- Workaround:
Press the reload button (this will fork a new image fetcher thread);
if that does not help, terminate (close) the viewer and open a new one.
- Status:
Fixed in rel3.2
- GL (3D graphics)related stuff
- The VGL/GL (and future openGL) operations are not synchronized w.r.t. smalltalk threads.
This can lead to problems, errors and even crashes.
- Description:
Operations like begin_line ... end_line could be preempted by another smalltalk thread,
which could do all kind of other GL drawing operations. This is especially dangerous,
if the first thread was inside of a makeobject operation.
- Workaround:
Add critical sections (Semaphore forMutualExclusion / sema critical) around your operations,
to make certain that sequences of drawing operations are executed in sequence, iff
you use background processes for animation.
- Status:
Open
- Drawing / Filling with a pattern
Under Windows-95, only mask-patterns with a size of 8x8
are supported on the windows display device.
(this can be seen in the DrawTool, where some fill patterns
are truncated to 8x8)
This is a limitation of windows-95; not a smalltalk problem.
- Line Drawing with a lineStyle
Under Windows-95, the #dotted, #dashDot and #dashDotDot styles
do not work on the windows display device.
- Font handling
All font handling code needs to be rewritten, to correctly
handle the Windows font naming conventions.
For now, dont expect to be able to write a MS-Word clone
with ST/X.
- Socket implementation
The current versions #readWait implementation does not work
if you readWait for incoming connections (i.e. when listening).
This is due to a limitation in Windows, where WaitForObject does
not handle sockets correctly.
As a workaround, use #waitForNewConnectionWithTimeout or
#waitForNewConnectionOrData, which are found in the Sockets instance protocol.
This is a temporary kludge-wrokaround.
Here is a list of things which we consider weak spots and which will be
fixed/changed in the near future.
- Font naming & handling
Currently, a postscript font naming scheme is used, which keeps attributes somehow encoded
in the fonts name (i.e. 'Courier-medium-oblique-10').
Although this works ok on X based display systems, it makes writing portable
applications somewhat difficult.
This will be changed to use a base-font name, family and a set of attributes
(such as italic, weight etc.), and will allow for the same naming
scheme to be used with different types of graphic displays.
Doc $Revision: 1.23 $ $Date: 2001/09/10 19:09:46 $