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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
