asp.net 4.0 with apache does not seem to work on trusty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xsp (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This is a sister-bug to #1292567 which reports a similar problem with asp.net 2.0. I have created two different reports, because the faults manifests themselves very differently, depending on the asp.net version.
I have created an extremely small ASP.NET application (attached as a tar file).
When I run that against the apache server on "saucy salamander", using mono-server4, it runs just fine.
When I run it against the apache server on the current beta of "trusty tahr", using mono-server4, the mono-server4 dies with a SIGABRT. The client gets a "500" error and the mono process running /usr/lib/
Luckily there is a good description in the apache error log:
Stacktrace:
at <unknown> <0xffffffff>
at Mono.WebServer.
at Mono.WebServer.
at (wrapper remoting-
at Mono.WebServer.
at Mono.WebServer.
at (wrapper runtime-invoke) <Module>
Native stacktrace:
Debug info from gdb:
=======
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=======
So, as you see, the SIGABRT occurs in a basic mono runtime routine called from the mod-mono-
module. Of course, I cannot know whether the bug that causes the abortion is in xsp or in basic mono. But
any search after the bug would start in mod-mono-server4, so I chose to file the bug against that package.
I have the same bug on my company's larger ASP.NET application.
This report is not made from the "trusty" installation, that one is a test installation without access to the net, so you don't get all the stuff that apport would collect to you. Honestly, you don't need it to reproduce, just grab a pristine trusty installation and try it!
However, a few important package versions:
libapache2-
mono-complete: 3.2.8+dfsg-4ubuntu1
mono-apache-
I am willing to offer any possible kind of assistance in fixing this problem - my company had looked forward to upgrade to "trusty". But, to be honest, I don't think you really need my help - the problem is so trivial to reproduce, it ought to be pretty trivial to fix if you know the ropes.
best regards
Peder Chr. Nørgaard
Changed in xsp (Ubuntu): | |
assignee: | nobody → shahid khan (shahid-mrd) |
assignee: | shahid khan (shahid-mrd) → nobody |
Changed in xsp (Ubuntu): | |
assignee: | nobody → shahid khan (shahid-mrd) |
assignee: | shahid khan (shahid-mrd) → nobody |
I have some additional information on this bug - not anything like a solution, but an idea about the direction in which to search.
As was clear from the original posting, the crash occurs in Mono.WebServer. VPathToHost. CreateHost. I have now narrowed it down to the call of System. Web.Hosting. ApplicationHost .CreateApplicat ionHost, to be precise, in line 150. Test output determines that the program reaches the point of this call, but the call never returns.
Now, CreateApplicati onHost is part of mono, not of xsp. So I went and added an exception throw to CreateApplicati onHost, as the very first thing to do, compiled and installed the modified System.Web.dll and tried again. No change, the mod-mono-server4 still crashes the same way.
On the other hand, if I earlier ran the application through xsp4, it has always gone fine - until I made this change - now it crashes, but with my exception. This was just to ensure that I hadn't bungled up the modification of System.Web.dll.
So to my thinking the real problem is actually in calling a method in a standard Mono .NET module. Could it be related to the fact that CreateApplicati onHost is compiled as UnManagedCode? or some of the security issues around CreateApplicati onHost? It is hard to imagine, and even harder to imagine why it works fine in xsp4 but crashes so spectacularly in mod-mono-server4. After all, much of the code (including the calling method, VPathToHost. CreateHost) is shared between the two solutions.
best regards