[Tcl-bugs] [Bug #119400] EOF sent/received too early or possible bug in http package

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

Bug #119400, was updated on 2000-Oct-25 22:12
Here is a current snapshot of the bug.

Project: Tcl
Category: Other IO
Status: Open
Resolution: None
Bug Group: 8.3.1
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: EOF sent/received too early or possible bug in http package 

Details: 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

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=119400&group_id=10894