Known Bugs in TclPro 1.0

• 1.1 Known Bugs List.
• 1.2 Known Bugs List.
• 1.3 Known Bugs List.

Known Bugs Index

1. TclPro 1.0

1.1. conflicting DLLs: error finding an entry point in tcl80.dll

Bug ID 433
Note that this applies to Windows only.
A potential conflict exists if both TclPro and Tcl/Tk 8.0p2 are installed on a machine. If you create a TclPro extension, or generate a wrapped executable, you may not be able to run the executable: the system will pop a dialog box stating that some "procedure entry point ... could not be located in the dynamic link library tcl80.dll". This is because the runtime linker has found, and loaded, the 8.0p2 DLL instead of the TclPro one.

In order to understand this behavior, you need to know about the search algorithm for DLLs used by the LoadLibrary function. When the system loads a DLL, it searches for it in the following locations in this order:

1. the directory from which the executable loaded
2. the current directory
3. the system directories
4. the Windows directory
5. the directories listed in the PATH environment variable

The first match terminates the search. The location of the system directories and Windows directory change depending on whether you are on NT or 95. The TclPro DLLs are in the TclPro bin directory. If your application resides in a directory other than the TclPro bin directory, then steps 1 through 4 will not find a DLL, but 5 will because the TclPro bin directory was placed in your PATH at installation time. The correct DLL will be found. But if Tcl 8.0p2 is installed, a tcl80.dll exists in the system directory, and the runtime linker will succeed at step 3, but with the wrong DLL. Note that, if your application is in the TclPro bin directory, step 1 succeeds and the correct DLL is loaded.

3 Work Arounds:

1. Uninstall Tcl 8.0p2. This is the cleanest workaround, unfortunately it means you won't be able to use Tcl 8.0p2. But TclPro is still an 8.0 release, so that your scripts should work as they are if you use protclsh and prowish instead of tclsh and wish.

2. Install your Tcl 8.0p2 executables in the TclPro bin directory. If you do that, the correct DLLs will be found, and you can still use 8.0p2. The disadvantage of this workaround is that you have to place your binaries in the directory hierarchy of a third-party product, where you don't have as much control; maintenance may be more complicated.

3. Move the following files from the system directory to the Tcl 8.0p2 bin directory: tcl80.dll tk80.dll. This lets you keep the 8.0p2 distribution, and lets you place your executables in directories of your choice. The drawback is that now you may start having problems while running Tcl 8.0p2 executables, because under some conditions the 8.0p2 executables may load the TclPro DLLs. Here's how this could happen:

Assume that your TclPro distribution is in c:\TclPro and Tcl 8.0p2 in c:\Tcl. If your PATH environment variable contains neither c:\Tcl\bin nor c:\TclPro\win32-ix86\bin, the DLLs won't be found. If PATH contains only c:\Tcl\bin, your TclPro apps will show the "missing entry point" behavior described above. If PATH contains only c:\TclPro\win32-ix86\bin, the TclPro apps will work, but 8.0p2 apps will fail at startup time with the message that _Tcl_Main cannot be located in tcl80.dll. This is because the incorrect DLL was loaded. If PATH contains both, one or the other will fail depending on the order of c:\Tcl\bin and c:\TclPro\win32-ix86\bin: if c:\Tcl\bin is before c:\TclPro\win32-ix86\bin, 8.0p2 apps will work and TclPro apps will fail with the "missing entry point" error. If the order is reversed, TclPro apps will work and 8.0p2 apps will fail because the _Tcl_Main entry point can't be found.

If you decide on this third workaround, you may have to wrap your executables with a batch file that sets up PATH so that the correct DLLs are loaded.

1.2. I index my [incr Tcl] and [incr Tk] files with auto_mkindex, and some of my classes are not indexed correctly.

Bug ID 467
There are conditions under which methods or classes that live in separate files are not found when the program runs. If you look at the tclIndex file generated from indexing those files, it will not contain entries for the commands in question.

The problem is that auto_mkindex is set up to look for the [incr Tcl] commands in the itcl namespace. If the script does a "namespace import", auto_mkindex will notice this and correctly index the script. However, if the script only does a "package require Itcl" and relies on the "namespace import" in the pkgIndex.tcl file, auto_mkindex will fail to index calls to "class" that don't have the itcl namespace qualifier. So classes defined with "itcl::class" will get indexed, but classes defined with "class" will not.

2 Work Arounds:

1. The simplest solution to the problem is to ensure that every file that contains class definitions or bodies that should be indexed also contains the following lines at the top:

    package require Itcl
    namespace import -force ::itcl::*

or

    package require Itk
    namespace import -force ::itcl::*

This work-around has the disadvantage that your scripts have to be modified.

2. If changing your code as described in 1) is not feasible or desirable, then you can add the following line to the end of lib/itcl3.0/itcl.tcl:

    auto_mkindex_parser::slavehook {
        _%@namespace import -force ::itcl::*
    }

This will cause auto_mkindex to automatically import the itcl namespace before indexing a file. With this workaround, you don't need to modify your sources. However, you have modified a system file which is likely to be overwritten by updates to the TclPro distribution; it is your responsibility to make sure that your change is merged into later releases if necessary.

Once you have made one of the modifications described above, start protclsh or prowish and re-index your [incr Itcl] and [incr Tk] files.

1.3. After executing "package require tbcload" successfully, tbcload commands are not found due to an error in the pkgIndex.tcl file.

Bug ID 517
Note that this applies to Unix only.
The pkgIndex.tcl file in <TclPro>/<platform>/lib has an incorrect line for the tbcload package. This means that executing "package require tbcload" will not properly load tbcload commands.

2 Work Arounds:

1. Change the pkgIndex.tcl file to contain this line for the tbcload package:

   package ifneeded tbcload 1.0 \  
       [list tclPkgSetup $dir tbcload 1.0 \  
            [list [list libtbcload10 [info sharedlibextension] \  
                  load {::tbcload::bceval ::tbcload::bcproc}]]]

2. Load the tbcload package manually instead of doing package require. For example:

   load <TclPro>/<platform>/lib/libtbcload10.so Tbcload

2. TclPro Debugger 1.0

2.1. TclPro Debugger should exit gracefully instead of giving an error message: can't read "sock": no such variable when a user tries to bring it up on a Windows 95 machine that does not have networking installed.

Bug 827
TclPro Debugger uses socket to communicate with the application you are debugging. This error is raised if you do not have networking installed on your machine. You can set up networking even though you do not have a network card by installing the Microsoft Dialup adapter and add the Microsoft TCP/IP protocol to this adapter.

2.2. The errorInfo variable is sometimes littered with debugger code.

Bug ID 147, 390
TclPro Debugger corrupts the errorInfo variable because internal routines show up in the error stack. This is a side effect of instrumentation. Just ignore the DbgNub stack frames.

2.3. ignored breakpoints on comment lines, empty lines, and curly-brace lines.

RFE ID 93, 97
TclPro Debugger will not stop on breakpoints set on lines that do not start a command (e.g. whitespace, comments, curly braces). This happens because breakpoints are recorded by line number and each command is associated with the line that it begins on. A breakpoint only triggers when a command is about to execute that has the same line number as the given breakpoint.

2.4. no way to see the return value of the target application.

RFE ID 95
There is no way to see the return value of the target application.

2.5. no way to see the return value of the result of subexpressions while single stepping

RFE ID 24
The debugger does not display the result of subexpressions while single stepping. It also does not show the result of a proc invocation, source command, or the program exit code.

2 Work Arounds:

1. Assign each subexpression to a temporary variable so the result can be checked.

2. Alternatively, if the subexpression has no side effects, it can be cut and pasted into the eval console.

2.6. debugger stops more than once on a breakpoint line.

Bug ID 75
Line-based breakpoints cause the debugger to stop before executing each command and subcommand on the specified line. To avoid this bug, you can break Tcl statements across multiple lines so each command begins on a different line.

2.7. TclPro Debugger appears to ignore line breakpoints set before a script runs.

Bug ID 98
In some cases, the path of a file used by TclPro Debugger does not match that used by the program that sources the file. The result is that breakpoints set in the file before the program starts will not be triggered.

2 Work Arounds:

1. Make sure to open the file using the same path as the program uses.

2. Set breakpoints after the first time the file is sourced.

2.8. Incr Tk fails with error messages like: cannot use "_initOptionInfo" without an object context

Bug ID 471
[incr Tcl] must be loaded before Itk or there will be bad function pointer references internally due to a bug in [incr Tcl].

Work Around:

Ensure that itcl30.dll is loaded before itk30.dll. The easiest way to do this is to put "package require Itcl" before a call to "package require Itk". Note that the Iwidgets init code already does this so the problem is only likely to occur when Itk is being used without Iwidgets, or the code explicitly requires Itk before requiring Iwidgets.

2.9. debugger crashes shortly after I dismiss a parsing error in [incr Tcl] code

Bug ID 456
The instrumenter fails to reset some of the special handlers used to instrument itcl 3.0 code. If there is an error during instrumentation, things can get confused, particularly if you run an [incr Tcl] 3.0 script followed by an [incr Tcl] 2.2 script.

Work Around:

Run TclPro Checker on the script to find the bug, fix it, then quit and restart TclPro Debugger before running the fixed script in TclPro Debugger.

2.10. crashes when debugging [incr Tcl] 2.2 with a parsing error inside a class

Bug ID 457
TclPro Debugger crashes with the error: "called "gui::instrumentErrorHandler" with too many arguments" when trying to instrument a file with a parsing error inside an incr Tcl 2.2 class.

Work Around:

Run TclPro Checker on the script to find the bug, fix it, then try running the fixed script in TclPro Debugger.

2.11. TclPro Debugger does not kill my remote applications.

Bug ID 204
Kill button does not necessarily kill remote applications. It merely closes the socket. This will typically cause an error in the client, so in some cases this does in fact kill the application.

2 Work Arounds:

1. call "exit" in the eval console.

2. Kill the client from the remote machine.

2.12. Misaligned icons in margin to the left of code.

Bug ID 92
Small fonts cause misalignment between lines of code and icons to the left of code. This problem also occurs in the variable, watch, and breakpoint windows.

Work Around:

Choose a font with a height that is larger than the height of the icons. You can change your font via the Edit | Preferences menu.

3. TclPro Checker 1.0

3.1. crashes if standard out is closed

Bug ID 437
If you pipe the output from TclPro Checker through "more" and quit before it is finished writing to stdout, TclPro Checker generates a stack trace the next time it attempts to write to stdout. This is because TclPro Checker uses the "puts" command which writes a string to stdout. When the "more" command is terminated "stdout" is closed, and "puts" command generates a Tcl error.

3.2. incorrectly checking [incr Tcl] command "info which"

Bug ID 473
If you run TclPro Checker with "-use incrTcl2.1" or "-use incrTcl2.2", and your code calls the [incr Tcl] command "info which" with the -command switch, TclPro Checker crashes. If your code calls "info which" with the -variable or -namespace flags, TclPro Checker erroneously flags a "badSwitch" error. Unfortunately, there is no workaround for these bugs. However, they will be fixed in the next release of TclPro.

3.3. crashes if Tk command "grid configure" is called with certain bad arguments.

Bug ID 463
TclPro Checker crashes if your Tk code contains any one of the following commands:

    grid configure .a .a -column <value>
    grid configure .a .a -columnspan <value>
    grid configure .a .a -row <value>
    grid configure .a .a -rowspan <value>

where <value> cannot possibly be a whole number. That is, <value> can be a whole number if it is either a subcommand, referenced variable, or non-negative integer.

Work Around:

If you encounter this bug in TclPro Checker, it means the code you are checking calls the "grid configure" command with a bad whole number argument. Once you fix the bug in your code, this TclPro Checker crash will no longer occur.

3.4. crashes when the trace command is called with an illegal operation

Bug ID 464
TclPro Checker crashes whenever the trace command is called with a bad operation argument.

    trace variable varname <operation> script
    trace vdelete varname <operation> script

where <operation> is not a legal option. That is, <operation> can be a legal option if it is either a subcommand, referenced variable, or a string consisting of any combination of the characters 'r', 'w', and 'u'.

Work Around:

If you encounter this bug in TclPro Checker, it means the code you are checking calls the trace command with an illegal operation. Once you fix the bug in your code, this TclPro Checker crash will no longer occur.

3.5. reports false "numArgs" error when upvar or lsort is called with a substituted switch

Bug ID 193, 301, 307
The following are examples of Tcl code that will cause TclPro Checker to erroneously report a "numArgs" error:

    upvar $level $varName var
    lsort $opt $l

The $level and $opt are legal and the "numArgs" error should be ignored.

3.6. reports false "badSwitch" error when lsearch or return arguments begin with '-'

Bug ID 294, 300
Whenever a command is called that accepts switches and arguments, TclPro Checker reports an error if the argument begins with a '-'. TclPro Checker erroneously assumes that this word is a switch because of the leading '-' character. The following are examples of Tcl code that will cause TclPro Checker to erroneously report a "badSwitch" error:

    lsearch {-one -two} $a
    return "-type cannot be changed"

3.7. reports false "badEvent" error for events Key-Page_Up and Key-Page_Down

Bug ID 267
TclPro Checker reports the "badEvent" error for the following commands:

    bind $w <Key-Page_Down> $script
    bind $w <Key-Page_Up> $script  

These events are only legal events on Unix systems, so TclPro Checker should flag a "nonPortEvent" warning instead of a "badEvent" error.

Work Around:

Ignore the "badEvent" warnings by using the "-suppress badEvent" switch on the procheck command line.

3.8. incorrect checking of the "event generate" command

Bug ID 459
If the <event> argument is missing but optional switches are passed as arguments, TclPro Checker does not flag a warning. TclPro Checker should warn that the event is missing in the following line of Tcl code:

    event generate . -keysym a

The correct composition of the "event generate" command is the following:

    event generate . <event> -keysym a

3.9. undocumented "upgrade" warning

Bug ID 453
When TclPro Checker is called with "-use tk<version>" where <version> is a Tk version prior to 8.0, and it encounters code containing Tk syntax that is no longer supported in later Tk versions, it flags an "upgrade" warning. The "upgrade" warning simply means that TclPro Checker will flag a "warnDeprecated" warning when the same code is check with "-use tk8.0". For example, if you run TclPro Checker with "-use tk3.6" on the following script, you will get the "upgrade" warning:

    scrollbar .a -background $a

Work Around:

Ignore the "upgrade" warnings by using the "-suppress upgrade" switch on the procheck command line.

3.10. error location indicator (^) points to wrong location

Bug ID 332
When checking poorly formed lists or the list command called with a bad number of args, the error location indicator (^) does not point to the correct location in the command. For example:

Z:/ws/pro/srcs/checker/foo.tcl:3 (numArgs) wrong # args
tk_getSaveFile -filetypes x
^

The caret should point to the argument "x" indicating that the argument to the "-filetypes" flag, "x", should be a list containing more than one argument/element.

4. TclPro Compiler 1.0

5. TclPro Wrapper 1.0

5.1. file paths on prowrap command line must match the file paths accessed in Tcl code

Bug ID 397
The archive created to hold all wrapped files contains a file entry list. Each entry in the list has the file name pattern that matches exactly as it appeared on the "prowrap" command line used to wrap the application (except any stripping of leading "-relativeto" directory specification). During runtime of the wrapped application, any file reference to a wrapped file must have the exact pattern specification as that in the file entry list--no filename resolution is performed for either the file reference or the wrapped file name.

2 Work Arounds:

1. Change your Tcl code so that file references match exactly those in the file entry list on the prowrap command line. If the command line was written as "prowrap ../foo/foo.tcl" then use the following Tcl code to access the file:

    set prefix ../ 
    source [file join $prefix foo foo.tcl]

A caveat to this workaround is that you will need to choose a consistent file reference semantic for each access of a given file.

2. If you want to avoid changing your Tcl code at all costs, you can use this workaround: change the prowrap command line to match the file references made in code. If the following legacy code was written:

    file exists ./../foo/bar.tcl
    open ./bar.tcl
    file exists .././fuzz.tcl

(where the same bar.tcl file is accessed by 2 different paths) then the prowrap command line should should resemble the following:

    prowrap ./../foo/bar.tcl ./bar.tcl .././fuzz.tcl

The drawback to this workaround is that files may need to be wrapped multiple times, thereby enlarging your wrapped application.

5.2. Tcl "glob" command doesn't find files wrapped in an application

Bug ID 348
TclPro Wrapper does not support the "glob" command for retrieving a list of wrapped file name paths. The result of a call to the "glob" command will not include any files from the list of wrapped files.

Work Around:

Applications that depend on the "glob" command to produce arbitrary lists of wrapped files will need to be rewritten to produce explicit lists of wrapped files.

5.3. wrapped application can't access Tcl library packages http1.0 or http2.0

Bug ID 399
The manifestation of this bug is that your wrapped application gets the error message, "can't find package http 2.0" when it calls the command:

    package require http 2.0

Although the set of files in the "http" package are indeed wrapped as part of the Tcl 8.0 library script files, the package mechanism employs the "glob" command to locate packages in subdirectories of entries in the "auto_path" variable. And since "glob" command does not recognize wrapped files or directories (see Bug ID 348), any packages that may exist in directories listed in the "auto_path" variable are not found.

Work Around:

A simple workaround to this problem is to add the following argument to your prowrap command line:

    -code "lappend auto_path lib/tcl8.0/http2.0"

5.4. on Windows, prowrap doesn't append ".exe" to output files specified by "-out" flag

Bug ID 462
On Windows, if the "-out" flag names a file without an extension, "prowrap" should automatically append the ".exe" so that it produces an executable file. TclPro Wrapper currently creates a file with no extension.

Work Around:

The workaround for this bug is to make sure you that when you specify "-out " on your prowrap command line, includes the ".exe" extension.

5.5. wrapped application can't access [incr Widgets] package

Bug ID 703
[incr Widgets] provides itself as a package by appending its lib directory onto the auto_path variable. When it does so, it adds an absolute path.

This is a problem when the wrapped application is run on a machine other than the one on which it is created. If the other machine does not have TclPro installed in the identical location, the [incr Widgets] commands cannot be auto-loaded because TclPro Wrapper sees an absolute path in the auto_path, and looks in the file-system for the [incr Widgets] library scripts instead of inside the wrapped application.

2 Work Arounds:

1. Add the following command before the "package require Iwidgets" command:

    lappend auto_path lib/iwidgets

2. Add the following argument to your prowrap command line:

    -code "lappend auto_path lib/iwidgets"

6. [incr Tcl] 3.0

6.1. The Man Page tab in the [incr Widgets] Catalog program does not work

Bug ID 500
Selecting the Man Page tab in the [incr Widgets] Catalog program results in a stack trace.

6.2. Incorrect permission on "mkinstalldirs" and "install.sh" files in the source directory for [Iincr Tcl] 3.0.1.

Bug ID 838
Note that this applies to Unix only.
The execution permission is not set for the following files:

<TclPro>/src/config/mkinstalldirs
<TclPro>/src/config/instal.sh

Work Around:

Add the execute permission as follows:

        % chmod +x mkinstalldirs
        % chmod +x instal.sh

This is the main Tcl Developer Xchange site, www.tcl-lang.org .    About this Site | [email protected]
Home | About Tcl/Tk | Software | Core Development | Community | Documentation