[Mono-list] mono-fastcgi-server on 64-bit os?

[Chris Rokusek]

Hi,

 

Well the usual gotchas are:

 

   1) Typecasting from signed values like -1 byte (0xff).  

   For instance -1 could become 0xffff.  Should check high and low order bytes.

   Maybe the += right side should be cast to (ushort)?

 

   2) Endian reversed (when the binary data was written on a different arch).  

   The bytes would be consistently reversed for that case.

 

If your debugger can shows vars in hexadecimal then you might set a breakpoint on the length read, and step into there and watch the conversion.

 

Chris

 

From: mono-list-bounces at lists.ximian.com [mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Doug
Sent: Tuesday, May 10, 2011 8:13 PM
To: mono-list at lists.ximian.com
Subject: [Mono-list] mono-fastcgi-server on 64-bit os?

 

Hey,

 

I'm slowly getting a bit further with the whole mono webserver thing, but I've hit another snag.

 

I'm tracked the problem to xsp-2.10/src/Mono.WebServer.FastCgi/Record.cs:

 

    internal static ushort ReadUInt16 (byte [] array,

                                       int arrayIndex)

    {

      ushort value = array [arrayIndex];

      value = (ushort) (value << 8);

      value += array [arrayIndex + 1];

      return value;

    }

 

This function is returning really odd values, specifically breaking this and forcing it to hang when this code is run:

 

    private static void ReceiveAll (Socket socket, byte [] data, int length)

    {

      if (length <= 0)

        return;

 

      int total = 0;

      while (total < length) {

        total += socket.Receive (data, total,

          length - total,

          System.Net.Sockets.SocketFlags.None);

      }

    }

 

Since the request length read is read using ReadUInt16, and the value coming out of that is about a thousand times larger than the actual body length, it hangs on socket.Receive; which in turn causes xsp4 to throw a code 500 because (as far as I can tell) thats what it does the fastcgi server times out.

 

I've seen a few posts about using MemoryStream and BinaryReader to do a ReadUInt16 that works correctly, but my lame attempts to patch the code and make it work were entirely unsuccessful (and to be honest I'm not even sure why it's not working; should the << 8 be << 16 for 64 bit?)

 

Can anyone point me in the right direction here?

 

~

Doug.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20110510/ed4b5390/attachment.html