Recent changes to bugs

bad stack top in nested [dict for]

2013-06-06T14:26:15Z

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]

2013-06-06T14:12:39Z

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

return in expr mangles the stack

2013-06-05T21:22:32Z

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

2013-06-05T13:31:25Z

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

Memory leaks in compiled code

2013-06-01T21:03:55Z

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]

2013-05-29T15:43:56Z

% 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

2013-05-24T16:55:03Z

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

2013-05-21T18:59:34Z

[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

2013-05-20T17:42:15Z

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

2013-05-18T18:43:10Z

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)