Recent changes to bugs

bad stack top in nested [dict for]

Don Porter — Thu, 06 Jun 2013 14:26:15 -0000

Using a --enable-symbols=all build of either the trunk,
or the 8.6.0 release:

$ cat demo.tcl
apply {{} {
dict for {a b} {c d} {
dict for {e f} {g h} {
return 5
}
}
}}
$ make shell SCRIPT=demo.tcl
...
Bad stack top 4 at pc 104 in TclNRExecuteByteCode (min 0, max 3)
executing dict for {e f} {g h} {
return 5
}
TclNRExecuteByteCode execution failure: bad stack top
make: *** [shell] Abort trap

bad stack top in nested [dict for]

Don Porter — Thu, 06 Jun 2013 14:12:39 -0000

Using a --enable-symbols=all build of either the trunk,
or the 8.6.0 release:

return in expr mangles the stack

Donal K. Fellows — Wed, 05 Jun 2013 21:22:32 -0000

This crashes in a full debug build (without the optimizer work I'm going to commit very soon):
apply {{} {expr {[return foo] + $a + $b}}}

Error is:
bad stack adjustment when compiling expr (was 0 instead of 1)

I believe (from scanning the fossil history) that you may have fixed something in this area. (Note that I don't know what bytecode sequence is generated; disassembling hits the same panic.)

basic-46.1 hangs

Don Porter — Wed, 05 Jun 2013 13:31:25 -0000

On the trunk, in a --enable-symbols=all build,
test basic-46.1 never returns.

Memory leaks in compiled code

Donal K. Fellows — Sat, 01 Jun 2013 21:03:55 -0000

This procedure leaks memory when run (or would if it didn't crash):

proc foo {} {while 1 {list a [list b [continue]]}}

The problem? The INST_CONTINUE doesn't clear things down. (This is a general problem if we've got a [return -code continue]; this is all work-in-progress.) So we add tracking of stack depth (dkf-compile-improvements branch) so we can issue the right number of INST_POPs and it hangs without memory consumption, absolutely correctly. Yay!

Let's try in our enhanced code with a new procedure:

proc foo {} {while 1 {puts {*}[puts {*}[continue]]}}

This is now worse; it leaks memory like it is going out of fashion! The problem is that we've got a build-up on the TD->auxObjList that can't be cleared.

I've not analyzed what happens when there's a [catch] involved.

stack imbalance panic from [list]

Don Porter — Wed, 29 May 2013 15:43:56 -0000

% proc foo {} {
list [append ::dgp a b c]
}
% foo
bad stack adjustment when compiling list (was 2 instead of 1)

panic in [array set] compiler

Don Porter — Fri, 24 May 2013 16:55:03 -0000

In a --enable-symbols=all build of the trunk:

$ make shell
...
% array set foo 4
bad stack adjustment when compiling array (was 2 instead of 1)
make: *** [shell] Abort trap

[file owned] undocumented Windows defects

Don Porter — Tue, 21 May 2013 18:59:34 -0000

[file owned] is useless on Windows, always returning true.

This is noted in comments, but not documented.

lsort -nocase does not sort non-ASCII correctly

Ashok P. Nadkarni — Mon, 20 May 2013 17:42:15 -0000

From the chat

I don't expect the following two commands to give the same answer
[00:00] apn (wits) 93 % lsort [list \u101 \u100]
Ā ā
(wits) 94 % lsort -nocase [list \u101 \u100]
Ā ā
[00:01] apn With -nocase, I would expect the second command to return ā Ā
[00:02] yukonbob exits, stage left!
[00:02] apn just like
[00:02] apn (wits) 96 % lsort [list a A]
A a
(wits) 97 % lsort -nocase [list a A]
a A
[00:04] dgp file the bug

The issue boils down to MergeLists using strcasecmp which does not handle non-ASCII characters.

If a temporary file cannot be opened Tcl_LoadFile can crash

Roy Keene — Sat, 18 May 2013 18:43:10 -0000

copyToPtr can be NULL and it should be checked before passing it to Tcl_IncrRefCount()

http://core.tcl.tk/tcl/artifact/26a06b015bfec491bb32903223af5152b3ceeb0d?ln=3230-3231

Prelimnary patch attached, however after applying this patch I then get:
Tcl_FSGetFileSystemForPath called with NULL object
Segmentation fault (core dumped)