Bug 23737 - Houston... error during web request on Apache 2.4
Summary: Houston... error during web request on Apache 2.4
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Web (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-10-10 06:43 UTC by APS
Modified: 2017-10-20 19:11 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case (1.92 KB, application/zip)
2014-10-22 12:13 UTC, APS
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 23737 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description APS 2014-10-10 06:43:22 UTC
Hi,

I installed mono on a Centos 7 box with Apache 2.4 in order to serve aspx pages.
I had to use a patched version of mod_mono because the standard version 2.10 doesn't compile on Apache 2.4. It works pretty well but in some request, I've not been able yet to discover the case because it's not the same page every time, I obtain the following error:

System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.Exception: Houston...
  at Mono.WebServer.ModMonoRequest.GetClientBlock (System.Byte[] bytes, Int32 position, Int32 size) [0x00000] in <filename unknown>:0
  at Mono.WebServer.ModMonoWorker.Read (System.Byte[] buffer, Int32 position, Int32 size) [0x00000] in <filename unknown>:0
  at Mono.WebServer.ModMonoWorkerRequest.ReadEntityBody (System.Byte[] buffer, Int32 size) [0x00000] in <filename unknown>:0
  at System.Web.HttpRequest.MakeInputStream () [0x00000] in <filename unknown>:0
  at System.Web.HttpRequest.get_InputStream () [0x00000] in <filename unknown>:0
  at System.Web.HttpRequest.LoadWwwForm () [0x00000] in <filename unknown>:0
  at System.Web.HttpRequest.get_FormUnvalidated () [0x00000] in <filename unknown>:0
  at System.Web.HttpRequest.get_Form () [0x00000] in <filename unknown>:0
  at System.Web.UI.Page.DeterminePostBackMode () [0x00000] in <filename unknown>:0
  at System.Web.UI.Page.InternalProcessRequest () [0x00000] in <filename unknown>:0
  at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Web.UI.Page.ProcessException (System.Exception e) [0x00000] in <filename unknown>:0
  at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context) [0x00000] in <filename unknown>:0
  at System.Web.HttpApplication+<Pipeline>c__Iterator3.MoveNext () [0x00000] in <filename unknown>:0
  at System.Web.HttpApplication.Tick () [0x00000] in <filename unknown>:0

I found that the issue is located in xsp-2.10.2/src/Mono.WebServer.Apache/ModMonoRequest.cs

public int GetClientBlock ([Out] byte [] bytes, int position, int size) 
{
    if (SetupClientBlock () != 0) return 0;

    /*
     * turns out that that GET_CLIENT_BLOCK (ap_get_client_block) can
     * return -1 if a socket is closed
    */
    writer.Write ((int) ModMonoCmd.GET_CLIENT_BLOCK);
    writer.Write (size);
    Send ();

    FillBuffer (4);
    int i = reader.ReadInt32 ();
    if (i == -1)
        return -1;

    if (i > size)
        throw new Exception ("Houston...");

    FillBuffer ((uint)i);
    return reader.Read (bytes, position, i);
} 

I inserted some more log into the exception and this is the result:

System.Exception: Houston... 1363232375 vs 28360
System.Exception: Houston... 1835812708 vs 28525 

The exception is thrown because the value returned to mod_mono from apache (1363232375, 1835812708) is greater than the size requested by mono (28360, 28525, ...). 

I checked the history of mod_mono 3.8 that enables Apache 2.4 support but I saw nothing related to this kind of problem.
Comment 1 Zoltan Varga 2014-10-15 12:58:01 UTC
-> xsp.
Comment 2 APS 2014-10-22 12:13:16 UTC
Created attachment 8472 [details]
Test case

I created a small test-case. It consists in a page that performs consecutive postbacks increasing every time the size by adding text to a textbox.
After some variable loop count, less than 50 on my machine, the request fails with the reported error.
Hope it helps.
Comment 3 APS 2014-10-23 06:36:51 UTC
I see that the bug has been moved to xsp but I can confirm that the problem is on mod_mono because I tested the same test-case with xsp and it never throws errors.
Comment 4 APS 2014-10-23 12:46:54 UTC
Same problem is reported also in this old bug report https://bugzilla.xamarin.com/show_bug.cgi?id=16796
Comment 5 APS 2014-11-05 11:06:47 UTC
After further investigations I think that the problem is in the management of the socket that connects mod_mono with xsp.
For some (yet) unknown reason sometimes xsp reads the result of GET_CLIENT_BLOCK before mod_modo ends to write data. It happens to me only when the size of the page is more than 32Kb.
I've found a small non-elegant workaround adding a sleep before reading data. So I changed the above function in this way:

Send ();
		
System.Threading.Thread.Sleep(1);
	
FillBuffer (4);

It seems that a 1ms sleep it's enough to workaround the problem. Hope it helps to correct the problem definitively.
Comment 6 Carl 2015-09-02 17:30:33 UTC
I am no longer getting this error, thanks!  Adding the 1ms sleep fixes it.
Comment 7 Carl 2017-10-20 19:11:10 UTC
Unfortunately I am getting this bug again when the upload is very quick.  It just doesn't happen as often now.