Tcl Source Code

OriginalBugID: 6282 Bug
Version: 8.3.1
SubmitDate: '2000-09-18'
LastModified: '2000-09-20'
Severity: SER
Status: UnAssn
Submitter: techsupp
ChangedBy: welch
OS: Linux
OSVersion: Linux bugger 2.2.17 #1 Fri Sep 15 02:22:10 EEST 2000 i586 unknow
Machine: Various Pentiums
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Kristoffer Lawson

ReproducibleScript:
===============  Server:

variable firstread 1

proc accept {sock addr port} {
    fconfigure $sock -buffering none
    fconfigure $sock -blocking 0
    fileevent $sock r [list stuff $sock]
}

proc stuff {sock} {
    fileevent $sock r {}    ;# this was in the original code but with them
                            ;# it's very hard to reproduce!
                            ;# sudo nice -n -20 for sender should do the
                            ;# job... ;)

    if {[eof $sock]} {
                puts "***EOF***"
                exit
    }
    puts -nonewline stdout [read $sock]

    variable firstread
        variable delay

    if {$firstread} {
        set delay 0
        after 2000 {set delay 1}
        vwait delay
        ## send response
        puts $sock " "
        set firstread 0
    }

    fileevent $sock r [list stuff $sock]
}

socket -server accept 40010
vwait forever

=================== Client:

set addr [lindex $argv 0]

## called when data from remote end arrives.
proc cb {} {
        variable sock

        read $sock

        puts $sock "<callback firstsend>"
        puts $sock "<callback secondsend>"

        for {set i 0} {$i < 9000} {incr i} {
                puts $sock "test32432 test3211 $i"
        }

        puts $sock "<callback lastnormalsend>"
        puts $sock "all data ok"

        close $sock
        exit
}

## Open & configure
variable sock [socket $addr 40010]
fconfigure $sock -blocking 0
fconfigure $sock -buffering none

fileevent $sock r cb
# cb

puts $sock "start"

vwait forever

ObservedBehavior:
I am now fairly convinced this is a bug in Tcl8.3.1. When the client is run on a fast machine and
especially if it is niced to a high priority tha server receives an EOF before all the data is sent. This also
only seems to happen when the server has responded with some data first.

The reason for my suspicions is that the http package seems to be doing exactly the same with Tcl 8.3.1.
Ie. I might try to receive a large image but a chunk from the end is missing. When I do exactly the same
operation with Tcl8.2 or 8.0 I have no problems. Of course, this might be a bug introduced into
http but I couldn't see anything in the code that looked like it would cause that kind of behaviour and as we
have similar behaviour with scripts like the above I believe there really is something fishy in Tcl's IO
(specifically with sockets). 

This is rather awkward for us as we are building large systems around Tcl which quite heavily use the IO
facilities. Of course, this might have been fixed in 8.3.2 (I haven't been able to test that yet), but as I
couldn't find this bug listed specifically then I thought it better to report.

DesiredBehavior:
In the given script all of the data should be sent and outputted to the screen before the EOF notification.



I can repeat this with both 8.3.1 and 8.3.2 on Linux, but only
in the loopback case where the client and server are on the same host.
It works fine on Solaris loopback, and between Solaris and Linux boxes.
However, I had to comment-out the 
    fileevent $sock r {}    ;# this was in the original code but with them
                            ;# it's very hard to reproduce!
                            ;# sudo nice -n -20 for sender should do the
                            ;# job... ;)
call in the server's fileevent handler.  Without that it works - the
nice'ing doesn't have any effect.  So, it could be possible that setting
fileevents is perturbing the system somehow.
 
-- 09/20/2000 welch

Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

Logged In: YES 
user_id=75003

Closing this one, it is so old, likely out of date.

Logged In: YES 
user_id=75003

Talking with Kristoffer showed that the problem was not 
reproducible for older linux systems (They had Debian 
2.2.something) or IRIX. 

This suggests an OS problem, although we can't be sure.

Decision: This item stays open for now, but at lowest 
priority.

Logged In: YES 
user_id=75003

Trying 8.3.2 now ... Can't get the error for this either.

Diffing generic/tclIO.c shows changes, but none which
should have an impact on this. There are no changes 
in "generic/tclNotify.c" at all. Same for the unix
notifier "unix/tclUnixNotfy.c", i.e. no changes at all.

Logged In: YES 
user_id=75003

I tried to verify this using the current 8.3.3 from the CVS 
and 8.4cvs on a RedHat Linux 2.2.18, gclibc 2.1.3. I tried 
nice'd and not, with the fileevent at the beginning of the 
handler commented out and not, with stdout redirected and 
not. I never got the early EOF.

Kristoffer Lawson is <[email protected]>.

File Added - 10495: 219400.client

File Added - 10494: 219400.server

Logged In: YES 
user_id=75003

Extracted the inlined code, attaching it to the report
as proper files now.

(Maybe put into one of the Channel* categories instead?)