Tk Source Code

Running the test suite with current trunk [44b24118] (2015-08-31), I get some new failures compared to tcl 8.6.4 (on the same system and compile method).

Here are the clipboard failures. This is one of three parts of ticket [cc0ba319].

System: Win 8.1 64 bit Compiled with Makefile.VC with MSVC6 PSDK2003 or MSVC14

==== winClipboard-2.1 TkSelUpdateClipboard reentrancy problem FAILED
==== Contents of test case:

    clipboard append -type OUR_ACTION "action data"
    clipboard append "string data"
    update
    list [selection get -selection CLIPBOARD -type OUR_ACTION] [testclipboard]

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: CLIPBOARD selection doesn't exist or form "STRING" not defined
    while executing
"testclipboard"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: TK SELECTION EXISTS
==== winClipboard-2.1 FAILED

---- winClipboard-2.2 start


==== winClipboard-2.2 TkSelUpdateClipboard reentrancy problem FAILED
==== Contents of test case:

    clipboard append -type OUR_ACTION "new data"
    clipboard append "more data in string"
    update
    list [testclipboard] [selection get -selection CLIPBOARD -type OUR_ACTION]

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: CLIPBOARD selection doesn't exist or form "STRING" not defined
    while executing
"testclipboard"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: TK SELECTION EXISTS
==== winClipboard-2.2 FAILED

Francois Vogel gave the following remark to the clipboard failures:

Regarding winClipboard tests failures, something that might be linked has been reported in the newsgroup:

https://groups.google.com/d/msg/comp.lang.tcl/311rQcMZYJQ/r2s34jh2BwAJ

For the record: when fixing this I have inadvertently introduced another issue, now fixed, see [caaae89bd5].

Merged to core-8-6-branch and trunk.

great solution ! Thanks, Harald

I have proposed something that I think is better, see [cb29e7d7].

Now when such a clipboard test fails it spits:

==== clipboard-4.1 ClipboardLostSel procedure FAILED
==== Contents of test case:

    clipboard append "Test"
    selection clear -s CLIPBOARD
    clipboard get

---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.1 FAILED

Note the obtained result, it tells exactly what happened.

Also in the originally reported case:

==== winClipboard-2.1 TkSelUpdateClipboard reentrancy problem FAILED
==== Contents of test case:

    clipboard append -type OUR_ACTION "action data"
    clipboard append "string data"
    update
    list [selection get -selection CLIPBOARD -type OUR_ACTION] [testclipboard]

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: clipboard cannot be opened, another application grabbed it
    while executing
"testclipboard"
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $script"
---- errorCode: TK CLIPBOARD BUSY
==== winClipboard-2.1 FAILED

See the errorInfo, and the new TK CLIPBOARD BUSY errorCode?

I like this solution better than copy/pasting some explanation text into each possibly failing test (and forgetting some that could fail). Less code/tests maintenance required, same outcome.

Good. I may imagine to have a remark in the test description like:

test winClipboard-1.1 {TkSelGetSelection (test fails if VNC Viewer running))} -constraints win -setup {

So, we directly see it in the test protocoll.

There is such a note in the test file already.

I have added a more prominent mention there, see [9a03de4779]

Francois,

thank you for the follow up.

I can confirm that with tk8.6.9 test winClipboard 2.1 & 2.2:

• the tests do not fail with only Thunderbird, Firefox and Windows Explorer open
• fail when I open UltraVNC viewer

So your analysis is correct.

I only ran the tests in winClipboard.test and clipboard.test.

I admire your constant efforts to chase bugs !

Maybe, we should put an information in the title of the test: "may fail if other running application holds the clipboard"...

And close this bug ;-)

Thank you,

Harald

I have seen these winClipboard failures plus a few others already, on Vista, in core-8-6-branch. This was repeatable, more or less. With bisecting in mind, I could rewind back in time, compile, and they were still here.

The day after, I compiled again and they were gone.

Another day later I compiled from scratch again and they were present once more.

I didn't find yet the root cause for these intermittent failures. There must be something outside of Tk that the test suite expects some state of, that isn't always the case. I initially thought of the current *content* of the clipboard when starting the tests, of course, but it doesn't seem to be the case.

Now, debugging things I see that this call to OpenClipboard(NULL) returns NULL.

According to the Microsoft documentation, OpenClipboard fails if another window has the clipboard open.

Looking at my desktop environment, it was not obvious to me which one was having the clipboard permanently open. So I closed my apps one by one, running the tests in-between closures, until the test failure stopped. This designated "TightVNC Viewer" as the culprit. Closing it made the failure stop. Reopening it made the failure reappear. This application indeed allows to cut/copy/paste between my local environment to the remote machine I'm looking at, so it probably has the Windows clipboard open to that purpose.

Harald, as the original poster of the present ticket, does this scenario make sense to you? When you see the winClipboard failures, do you have any application also open that could keep the clipboard open for its use? Can you identify which one is the culprit, by running the tests and closing each app one by one after each test run?