[Openmcl-devel] wx86cl-Windows XP SP3 32bit-socket error #22 during write

[Gary Byers]

On Thu, 16 Apr 2009, John Miller wrote:

>
> On Apr 15, 2009, at 2:36 PM, Gary Byers wrote:
>
>> 
>> 
>> On Wed, 15 Apr 2009, John Miller wrote:
>> 
>>> I am running CCL 1.3-r1195 (WindowsX8632) and getting the below
>>> "(error #22) during write" when trying to connect to the Xming
>>> server (or is that client? never could get that straight) on my
>>> Windows XP, SP 3 machine.  I also get the same error when I try to
>>> connect to swank from Emacs using slime.
>> 
>>> I have another Windows XP machine that runs as a virtual machine
>>> under parallels and I do not have any problems running slime+swank
>>> on ccl on that machine (haven't tried clx, though).  I am stymied-
>>> which is admittedly a pretty easy thing to do- but I was wondering
>>> if anyone could provide insight into what an "(error #22) during
>>> write" means.
>> 
>> It means "The device doesn't recognize the command."  (I suppose that
>> you'll want to know what that means now. I don't know yet.)
>> 
>> On the machine that has problems, does networking generally work ?
>> E.g., is some network interface configured ? One would think that
>> that wouldn't matter much, since you're just trying to connect to
>> the loopback address, but this is Windows ...
>> 
>
> I also should add that I rebooted my Win machine in diagnostic mode, which 
> disables all the cruft my employer has placed on this machine, and I still 
> get the socket error.  I installed SBCL 1.0.22 and it runs the slime/swank 
> combo just fine.  Not sure what else I can check, and I believe I am the only 
> unfortunate slob in the CCL universe with this problem, so I have a feeling 
> this one is going to remain a mystery.
>
> Thanks anyway...


Confusingly, there are a couple of different sets of error numbers
that can be relevant under Windows:

  - some functions return (perhaps indirectly, by setting the "errno"
    thread-local variable) a POSIX error number to indicate an error.

  - many functions return (in another thread-local variable that can
    be accessed via #_GetLastError) a Windows error code.

The actual numbers can conflict, but conflicting POSIX and Windows
error numbers generally have nothing to do with each other.

In the case where you get an "error 22" during FD-STREAM-FORCE-OUTPUT,
we're interpreting the "22" as a Windows error number:

? (ccl::%windows-error-string 22)
"The device does not recognize the command. "

but the function that failed actually returns a POSIX error number:

? (ccl::%strerror 22)
"Invalid argument"

I don't know which of these is more generic and less helpful, but
I actually think that the POSIX interpretation may be very slightly
helpful.  The function that generates the error is a call to WriteFile
in the function lisp_write (in ccl/lisp-kernel/windows-calls.c):

   if (WriteFile(hfile, buf, count, &nwritten, &overlapped)) {
     return nwritten;
   }

   err = GetLastError();
   _dosmaperr(err);         /* map Windows error to POSIX error, set errno */
   return -1;

So, the call to WriteFile is returning a Windows error number that gets
mapped to EINVAL (=22).  If you look at the function _dosmaperr (in that
same C source file), you'll see that a small number of Windows errors
are mapped to specific POSIX errors and anything not enumerated gets
mapped to EINVAL: we don't know with any confidence what WriteFile was
really complaining about.