[Mono-bugs] [Bug 82012][Nor] Changed - mod_mono not serving requests

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by mmorano at mikeandwan.us.

http://bugzilla.ximian.com/show_bug.cgi?id=82012

--- shadow/82012	2007-07-06 06:31:25.000000000 -0400
+++ shadow/82012.tmp.2462	2007-07-07 12:18:17.000000000 -0400
@@ -51,6 +51,50 @@
 which I believe is the last time I fully refreshed my environment to
 address the bug you fixed here:
 http://bugzilla.ximian.com/show_bug.cgi?id=81749.
 
 Thanks,
 Mike
+
+------- Additional Comments From mmorano at mikeandwan.us  2007-07-07 12:18 -------
+OK, well, I've looked into this more, and have a bit more info to
+report (but unfortunately no solution).  After performing a recent
+upgrade, all components were running r81551.  This still exhibited the
+same problems originally reported.  I then continued to perform more
+tracing, and ran into 2 odd problems.
+
+The first was that ApplicationHost calls AppDomain.CreateDomain which
+subsequently calls into RemotingServices.  The static constructor for
+RemotingServices calls RegisterInternalChannels() and then once that
+returns, it tries to obtain a new GUID.  Oddly enough, this process
+did not return properly.  After some further tracing, it calls
+RandomNumberGenerator.Create which eventually calls
+CryptoConfig.CreateFromName.  Here, it seemed as though there was a
+deadlock on the lock statement.  However, I tried to modify all the
+initialization code so that it was part of the static initializer to
+see if that would avoid the locking issue, and this did not work.  I
+then tried modifying the Guid.NewGuid() method so that it got the byte
+array from the FastNewGuidArray() method, and this then allowed the
+application to continue further, but still did not serve a page.
+
+Perhaps this is expected based on the hack above, but once it got past
+the Guid.NewGuid() call, it then got hung up in calls associated with
+RemotingServices and marshalling of AppDomains.  
+
+I will attach an updated trace immediately after this post that shows
+the process getting hung in CryptoConfig to provide a more detailed
+stack trace of the process.
+
+Finally, as the above descriptions suggest, the problem seems to be in
+mcs/mono and not the recent updates in mod_mono/xsp.  To test this, I
+reverted my mono and mcs to the last known working copy (r78042) while
+keeping mod_mono and xsp at the most recent version (r81551) and my
+website works again via apache/mod_mono.
+
+In case it is important, here is some basic info about my system:
+
+Linux aeris 2.6.20-gentoo-r8 #1 Sat May 19 15:25:10 EDT 2007 x86_64
+AMD Athlon(tm) 64 Processor 3800+ AuthenticAMD GNU/Linux
+
+
+Thanks,
+Mike