Tk Source Code

Test passes on core-8-6-branch; fails on trunk:

==== border-3.1 FreeBorderObjProc FAILED
==== Contents of test case:

    set x [join purple]
    button .b -bg $x -text .b1
    set y [join purple]
    .b configure -bg $y
    set z [join purple]
    .b configure -bg $z
    lappend result [testborder purple]
    set x red
    lappend result [testborder purple]
    set z 32
    lappend result [testborder purple]
    destroy .b
    lappend result [testborder purple]
    set y bogus
    return $result

---- Result was:
{{1 1}} {{1 1}} {{1 1}} {}
---- Result should have been (exact matching):
{{1 3}} {{1 2}} {{1 1}} {}
==== border-3.1 FAILED

OK, WILCO.

About this (for my own records):

I'm wondering why font-18.1 does not fail though. [b2677cc770] is a hint that is should fail identically.

This is because in this test we have

set x [join {Courier 12} { }]

http://core.tcl.tk/tcl/info/b24a53dd0c87c785

does therefore not enter in play.

Fixed on trunk.

Follow the same pattern to fix the 
other similar tests.

Test failure can be seen on Windows as well, with trunk, after fossil updating Tcl, as expected.

All three failures [76e2d9c095] (the present one), [ad98f10b3a] and [bd0017bf79] are due to the same issue.

I'm wondering why font-18.1 does not fail though. [b2677cc770] is a hint that is should fail identically.

These commands [testborder], [testbitmap]... et al. were here since the beginning of time, exposing internal refcounts and checking they did not change. The goal apparently is to make sure that allocation and freeing of the objects are correctly done by Tk. I have to think about how to check that without relying on Tcl implementation/optimizations. Help welcome, thanks...

The testborder command runs TkDebugBorder which reports resourceRefCount and objRefCount fields from TkBorder. The failing test reports that objRefCount is no longer the same.

Makes sense to me with the commit you found.

Since Tk testing has a need for such a thing,
Tk should just implement a testing command
that does it, instead of playing an endless
game of which Tcl command will have the right
magical side effect.

Apparently that was the answer the last
time we encountered the exact same problem.

Could this be related perhaps: [b2677cc770123a48]

I don't understand the above commit, but I note that you have just opened three bug reports on 3 newly failing tests among the four that were changed by the above commit.

This comes down to what the tests are testing.

The Tcl change is an optimization in [join] to
use existing values instead of copying them.
This changes internal details about refcounts
and copying patterns.

For some reason the [testborder] command
is raising such internal matters to script
visibility and checking that they have not
changed.  In particular it is reporting a
count of Tcl values that share the same intrep.
When sharing patterns stop producing multiple
copies of the same values, then there are
fewer such values sharing the intrep and
the results change.

These tests were relying on [join] to make
an unshared copy of its singleton argument.
It doesn't do that anymore.  We can change
all the [join foo] to [string range foo 0 end]
to get the side effect the test needs
(though that may change one day too).

Seems that this change to Tcl is the cause
of the failing test.

http://core.tcl.tk/tcl/info/b24a53dd0c87c785

Which on first sight makes no sense at all.

When this is deciphered, there's gonna be some
big surprise buried in the mess.

It appears that the difference between
success and failure is not in changes to Tk,
but in which branch of Tcl is in the mix.

I see the test failing on trunk, and passing on core-8-6-branch, with CentOS 7. Same as you do.

I don't see what could be causing this issue.

On my side this runs in a virutal machine and is VERY slow, to the point of being hardly usable.
Any chance you can fossil bisect on a real machine running CentOS 7? It is very very tedious for me with such a slow virtual thing.

Test no longer skipped after
  make clean ; make distclean
and running the test again.

But now the test passes. I can't reproduce.

`make test`

And this is because for me :

++++ border-3.1 SKIPPED: testborder

How do you run this test?

I suppose this happens on your CentOS Linux release 7.2.1511

make test TESTFLAGS="-file border.test"
is 100% oK for me on Debian 8.