[Tcl-bugs] [ tktoolkit-Bugs-703787 ] Tk 8.4.2 test on Solaris 7 unauthorizes DISPLAY :0.0

[SourceForge.net <no...@so...>]

Bugs item #703787, was opened at 2003-03-14 19:06
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=703787&group_id=12997

Category: 58. [send]
Group: = 8.4.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jonathan Leffler (jleffler)
Assigned to: Pat Thoyts (patthoyts)
Summary: Tk 8.4.2 test on Solaris 7 unauthorizes DISPLAY :0.0

Initial Comment:
Running on Solaris 7, using GCC 3.2.1 and Tcl/Tk 8.4.2,

I can run quite a lot of tests, but then the DISPLAY is

disabled so that neither Tk testing nor other

applications (eg Netscape) can connect any more:





tk.test

unixButton.test

unixEmbed.test

Error in startup script: unexpected EOF from

"/work4/open.source/Tcl/tk8.4.2/unix/tktest"

    while executing

"error "unexpected EOF from \[interpreter]\""

    (procedure "setupbg" line 10)

    invoked from within

"setupbg"

    (file

"/work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"

line 18)

    invoked from within

"::source

/work4/open.source/Tcl/tk8.4.2/tests/unixEmbed.test"

    ("uplevel" body line 1)

    invoked from within

"uplevel 1 [list ::source $file]"

    (procedure "tcltest::runAllTests" line 57)

    invoked from within

"tcltest::runAllTests"

    (file

"/work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl"

line 19)

make: *** [test] Error 1





...let's try again...





Anubis JL: make test

TCL_LIBRARY=/work4/open.source/Tcl/tcl8.4.2/library;

export TCL_LIBRARY; \

TK_LIBRARY=/work4/open.source/Tcl/tk8.4.2/library;

export TK_LIBRARY; \

./tktest

/work4/open.source/Tcl/tk8.4.2/unix/../tests/all.tcl

-geometry +0+0 \

 

Xlib: connection to ":0.0" refused by server

Xlib: Client is not authorized to connect to Server

Application initialization failed: this isn't a Tk

applicationcouldn't connect to display ":0.0"

Tests running in interp: 

/work4/open.source/Tcl/tk8.4.2/unix/tktest

Tests located in:  /work4/open.source/Tcl/tk8.4.2/tests

Tests running in:  /work4/open.source/Tcl/tk8.4.2/unix

Temporary files stored in

/work4/open.source/Tcl/tk8.4.2/unix

Test files sourced into current interpreter

...



I have to logout to get things back to normal again! 

There's one minor failure earlier:



listbox.test



==== listbox-13.3 ListboxScanTo procedure FAILED

==== Contents of test case:



    .l yview moveto 1.0

    .l xview moveto 1.0

    .l scan mark 10 20

    .l scan dragto 5 10

    update

    set x [list [.l xview] [.l yview]]

    .l scan dragto [expr 5+$width] [expr 10+$height]

    update

    lappend x [.l xview] [.l yview]



---- Result was:

{0.8 1} {0.75 1} {0.64 0.84} {0.25 0.5}

---- Result should have been (exact matching):

{0.8 1} {0.75 1} {0.62 0.82} {0.25 0.5}

==== listbox-13.3 FAILED



macEmbed.test





----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2003-08-27 16:41

Message:
Logged In: YES 
user_id=79902

Main issue fixed (it was even worse on SGI which requires

the Xserver to be xhost-enabled locally) in HEAD.  Minor

issue is duplicate.



Workaround: make test TESTFLAGS="-notfile send.test"

----------------------------------------------------------------------

Comment By: Pat Thoyts (patthoyts)
Date: 2003-06-27 10:03

Message:
Logged In: YES 
user_id=202636

It seems to me that the send.test script should simply skip

all the tests if the Xserver is incorrectly configured. The

send command is disabled unless xauth authentication is in

use and it's not reasonable for an application to override

such a server setting.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2003-03-17 14:05

Message:
Logged In: YES 
user_id=79902

The culprit is send.test, and the way that it tries to

secure the display, which is a total disaster if your

session is only possible because of xhost security.  Now

arguably this is due to a bug in the Xserver configuration

(xhost security sucks rocks) but it is a very widespread

one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112997&aid=703787&group_id=12997