---- Reported by grompf@sublimeintervention.com 2004-10-01 13:17:09 MST ----

Running xsp / mod_mono on HEAD is currently failing due to a jit bug.

I believe this is a similar one to the last stack (un)winding.  The call that is being improperly 
handled is in XSPApplicationHost.cs:

public void ProcessRequest (int reqId, long localEPAddr, int localEPPort, long remoteEPAdds,
                                        int remoteEPPort, string verb, string path, string pathInfo,
                                        string queryString, string protocol, byte [] inputBuffer, string redirect)

which is called from: XSPApplicationHost.cs:210.

I have modified this call locally to be:

host.ProcessRequest (requestId, this, rdata, redirect);

with the call signature:

public void ProcessRequest (int reqId, XSPWorker worker, RequestData rdata, string redirect)

This modification masks the JIT bug.

To replicate, run xsp/mod_mono from CVS HEAD, with mono from CVS HEAD and request the 
session1.aspx test.  Submit the callback a few times and you will get an exception.

I'm going to work more on atomicizing a cross-appdomain call that can replicate the same 
behaviour but have been unsuccesful so far..

-kangaroo



---- Additional Comments From grompf@sublimeintervention.com 2004-10-14 00:28:13 MST ----

I dug more into this bug today; and with further looking it appears this might not be a JIT 
bug.  It appears to be a socket blocking bug.  I'm not sure why my other patch masks this 
behaviour; but when setting the client socket to Blocking; XSP starts behaving as it should 
again.  Perhaps its a jit speed difference to x86 why this hasn't been noticed there?

-kangaroo

Index: ApplicationServer.cs
=======================================================
============
RCS file: /cvs/public/xsp/server/ApplicationServer.cs,v
retrieving revision 1.11
diff -u -r1.11 ApplicationServer.cs
--- ApplicationServer.cs        3 Oct 2004 22:02:40 -0000       1.11
+++ ApplicationServer.cs        14 Oct 2004 02:39:59 -0000
@@ -307,6 +307,7 @@
 
                                        allSockets.Remove (s);
                                        timeouts.Remove (s);
+                                       s.Blocking = true;
                                        IWorker worker = webSource.CreateWorker (s, this);
                                        ThreadPool.QueueUserWorkItem (new WaitCallback 
(worker.Run));
                                }



---- Additional Comments From grompf@sublimeintervention.com 2004-10-14 02:05:24 MST ----

This is definately not a jit bug; I've tracked the problem down to a socket bug.  On linux 
sockets from an accept () call have default flags.  On Darwin (possibly other BSDs?) they 
inherit the listeners flags.  Run the following program on linux and you will get (http://
cvs.apache.org/~jorton/nonblock.c):

plasma@calvin:~$ uname -a 
Linux calvin 2.4.6 #7 SMP Wed Mar 20 14:22:11 EST 2002 i686 unknown
plasma@calvin:~$ ./nonblock 
found port: 1184
O_NONBLOCK is not set in the child.

Run it on OSX and you get:
junglist:~ plasma$ uname -a
Darwin junglist.local 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug  5 19:26:16 PDT 2004; 
root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC  Power Macintosh powerpc
junglist:~ plasma$ ./nonblock 
found port: 64916

As a result you can see that the NONBlocking listener in XSP when accepting a new 
connection is defaulting to nonblocking on osx.  This behaviour is incorrect.

Proposed patch attached

Could someone with Net/Free/Dragonfly BSD please check to see what happens with 
socket flags (I dont have one to test on)?

Perhaps the #ifdef __APPLE__ should be a #ifdef __APPLE__ || __BSD__

-kangaroo




---- Additional Comments From grompf@sublimeintervention.com 2004-10-14 02:06:24 MST ----

Created an attachment (id=166866)
proposed patch




---- Additional Comments From dick@ximian.com 2004-10-14 06:50:54 MST ----

Patch committed to 1.0 and HEAD.

If you could let me know if this applies to other BSDs, and cook up
the required configure.in stuff that would be great (checking for
features is much better than checking platforms...)



---- Additional Comments From dick@ximian.com 2004-10-14 10:06:45 MST ----

And I've reverted it again :)

We decided that because the MS runtime sets newly accepted sockets to
the same blocking status as the listening socket, that XSP should be
fixed to cope, and that our Socket class now explicitly sets the
blocking status of newly accepted sockets.




---- Additional Comments From gonzalo@ximian.com 2004-10-14 13:24:52 MST ----

I fixed it in xsp.

Imported an attachment (id=166866)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>osx 10.3.5</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".