Known Bugs, Limitations 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 ;-)

Warning

This list is no longer maintained. We are now using expeccoALM for bug maintenance and communication. Please take a look at "https://expeccoALM.exept.de" for known bugs (you need an account - i.e. a maintenance contract to access this service).

General Bugs
Bugs in the Windows-95 / Windows-NT Version
Bugs in the MAC OSX Version
Bugs/Problems with Particular Displays
TODO

General Bugs

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 may 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
- Keyword Symbol constants within a literal array
  - are scanned wrong
    - Description:
      within a literal array, keyword symbols are scanned wrong; instead of #( #foo:bar: ) , the 2 element Array #( #foo: #bar: ) is parsed.
    - Workaround:
      use single quoted symbols, as in #( #'foo:bar:' ).
    - Status:
      open.
- 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.
- ifXXX 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.
- shadowing local variable names in inlined nested blocks
  - shadowing an outer scope-variable in an inlined ifXXX or whileXXX block's local leads to wrong (uncompilable) code to be generated sometimes. CC will fail with an "foo undefined" message
    - Description:
      The #undef of the variable at the end of an inlined block does not care to redefine the original (shadowed) reference. If the outer variable is accessed afterwards, the C-compiler does not have a definition for it and fails.
    - Workaround:
      Use a different name in the inner (inlined-block).
    - Status:
      fixed.
- 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:
      partially fixed:
      the bitmap storeString format has been changed to break long strings into multiple lines.
      Huge literal strings may still lead to a problem.
- Too much inlining
  - #not-message is always inlined - but always assuming that receiver is boolean (#not to non-boolean fails)
    - Failure reason:
      stc's inlining is too aggressive 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
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
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

Bugs of the Windows-95 / Windows-NT Version

Drawing / Filling with a pattern (closed - Win95 is no longer supported)
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 (closed - Win95 is no longer supported)
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 Window's font naming conventions.
For now, don't 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.
Maximization bug under XP
Maximization does not generate correct size-change events.
Fixed with rel4.x
Echo in the TerminalView
We could not figure out, how to configure the Console-Emulation of WinNT/2K/XP, to echo its input immediately (it works under W95/W98 !). The effect is that in the FileBrowser's terminal view, user-input is echoed when the <RETURN>-Key is pressed - not immediately as it should.
If anyone knows how to fix this, please let us know !

Bugs/Limitations of the Mac-OSX Version

Needs 10.6 or better
The development is done on a 10.6 system. I have no plans to support, check or validate backward compatibility with older OS versions.
No Native GUI Support
The prerelease of the MAC-OSX version uses the X Window system for the GUI. There is currently no support for any nativeG UI (Cocoa). Some low level mechanisms and interfaces to Objective-C have been written, but are not yet in a release state.
Unfinished Jitter
The jitter (bytecode to machine code compiler) is unfinished. It can currently only compile a subset of the full code set and will silently bail out for most methods. This is transparent to the user, as the code is still executed by the bytecode interpreter. Execution speed is somewhat slower for user-added code. However, as most of the system is compiled to machine code (by stc) anyway, this only affects execution speed during development. Compiled and deployed machine code runs at full speed.
Screen Readout does not work in XQuartz
The XQuartz X-server does not support reading pixels from the screen. Therefore the screenshot functions do not work at all, and the drag&drop operations do not show the dragged picture.
Currently, as a workaround, the system's screen-dump utility is called, and the resulting image file loaded. This is obviously much slower than a direct readout, but good enough for typical day-to-day usage.

Bugs/Problems with Particular Displays

Button State Bug in Exceed (an X-server for windows)
The Exceed X-server (which versions ?) has a bug in that if you grab the pointer for a popUpView, move the mouse pointer to a windows decoration area, release the grab, and finally re-enter the otiginal view, the incoming motion events still say that the original button is pressed.
This bug is especially inconvenient when a pullDown menu is opened via a short click and then the mouse clicked in the windows title area.
When reentering the menuPanel, menus reopen as if the mouse was still pressed.
Currently, there is no known programatic workaround for this (it does not happen with any other X-server).
As a user, do not close pullDown menus by clicking into the title area; press escape or click anywhere else.
Late note: a workaround has been found and implemented in rel4.1.5.

TODO

Doc $Revision: 1.46 $ $Date: 2018/05/12 07:18:44 $