[usocket-devel] SBCL wait-for-input bug on attempt at second connection

Sun May 1 05:41:09 UTC 2011

Hi, Elliott

Thank you, I've installed this SBCL binary and merged your test code into usocket's unit test [1]. And Yes, I can see the BAD-FILE-DESCRIPTOR-ERROR now. This happens only on SBCL/Windows but other platforms.  I also tried your test code on other CL implementations, it passed on most backends on Mac OS (CMUCL, SBCL, Allegro CL, Clozure CL) but strangely failed on LispWorks/Mac in another form, and hang forever on ABCL ...  Any way, let me try to fix SBCL/Windows first.

Regards,

Chun Tian (binghe)

[1] svn://common-lisp.net/project/usocket/svn/usocket/branches/0.5.x/test/wait-for-input.lisp

在 2011-5-1，01:48， Elliott Slaughter 写道：

> By the way (in case you have any trouble reproducing), the version of SBCL used to test this can be obtained here. (It's just a more up-to-date version than what you can get on the SBCL download page that I compiled myself.
> 
> http://elliottslaughter.net/files/sbcl-1.0.46.msi
> 
> 2011/4/30 Chun Tian (binghe) <binghe.lisp at gmail.com>
> Hi, Elliott
> 
> Sorry for late responses, I'm a little busy in the past week.
> 
> It seems that current implementation of WAIT-FOR-INPUT on SBCL/Windows have some bugs, I'll look into it in next two days and try to fix it.  Whatever bug it has, it shuold NOT be any bug in SBCL itself, because this function was completely written using SB-ALIEN and underlying Win32 API.
> 
> I'll put your code as part of usocket's unit test and see if it also affects other backends.
> 
> Regards,
> 
> Chun Tian (binghe)
> 
> 在 2011-4-25，09:17， Elliott Slaughter 写道：
> 
>> First, the documentation for wait-for-input says that only integer are accepted, but code seems to think reals should work. (Tested on SBCL/Windows.)
>> 
>> Second, I have found a bug in wait-for-input in SBCL on Windows. The problem is that a wait-for-input on a TCP server socket which has already accepted one client will continue to return that the socket is ready to accept more clients even though it isn't, and thus cause an error when I try to call socket-accept. Here is the code that breaks it:
>> 
>> (defvar *port* 12345)
>> (defvar *socket-server-listen*
>>   (socket-listen *wildcard-host* *port* :element-type '(unsigned-byte 8)))
>> 
>> (defvar *socket-server-connection*)
>> (setf
>>  *socket-server-connection*
>>  (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t)
>>    (socket-accept *socket-server-listen*)))
>> (format t "First time (before client connects) is ~s.~%"
>>         *socket-server-connection*)
>> 
>> (defvar *socket-client-connection*)
>> (setf *socket-client-connection*
>>       (socket-connect "localhost" *port* :protocol :stream
>>                       :element-type '(unsigned-byte 8) :timeout 0))
>> 
>> (setf
>>  *socket-server-connection*
>>  (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t)
>>    (socket-accept *socket-server-listen*)))
>> (format t "Second time (after client connects) is ~s.~%"
>>         *socket-server-connection*)
>> 
>> (setf
>>  *socket-server-connection*
>>  (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t)
>>    (socket-accept *socket-server-listen*)))
>> (format t "Third time (before second client) is ~s.~%"
>>         *socket-server-connection*)
>> 
>> The output on Windows/SBCL looks like:
>> 
>> First time (before client connects) is NIL.
>> Second time (after client connects) is #<STREAM-USOCKET {24757F91}>.
>> 
>> It doesn't get to the first format call, because it hits the following error first:
>> 
>> Condition BAD-FILE-DESCRIPTOR-ERROR was signalled.
>>    [Condition of type BAD-FILE-DESCRIPTOR-ERROR]
>> 
>> Restarts:
>>  0: [RETRY] Retry SLIME REPL evaluation request.
>>  1: [ABORT] Return to SLIME's top level.
>>  2: [ABORT] Abort
>>  3: [CLOSE-CONNECTION] Close SLIME connection
>>  4: [ABORT] Exit debugger, returning to top level.
>> 
>> Backtrace:
>>   0: (USOCKET::HANDLE-CONDITION #<SB-BSD-SOCKETS:SOCKET-ERROR {2475C889}> #<STREAM-SERVER-USOCKET {256F7C19}>)
>>   1: (SIGNAL #<SB-BSD-SOCKETS:SOCKET-ERROR {2475C889}>)
>>   2: (ERROR SB-BSD-SOCKETS:SOCKET-ERROR :ERRNO 9 :SYSCALL "accept")
>>   3: (SB-BSD-SOCKETS:SOCKET-ERROR "accept")
>>   4: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-ACCEPT (SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument> #<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:12345, fd: 6 {2576DD91}>)
>>   5: ((SB-PCL::FAST-METHOD SOCKET-ACCEPT (STREAM-SERVER-USOCKET)) #<unused argument> #<unused argument> #<STREAM-SERVER-USOCKET {256F7C19}> :ELEMENT-TYPE NIL)
>>   6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*) #<NULL-LEXENV>)
>>   7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (PROGN (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*)) #<NULL-LEXENV>)
>>   8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (WHEN (WAIT-FOR-INPUT *SOCKET-SERVER-LISTEN* :TIMEOUT 0 :READY-ONLY T) (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*)) #<NULL-LEXENV>)
>>   9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SETF *SOCKET-SERVER-CONNECTION* (WHEN # #)) #<NULL-LEXENV>)
>> 
>> -- 
>> Elliott Slaughter
>> 
>> "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay
>> _______________________________________________
>> usocket-devel mailing list
>> usocket-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
> 
> 
> 
> 
> -- 
> Elliott Slaughter
> 
> "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20110501/9eb95bf0/attachment.html>