asp.net 4.0 with apache does not seem to work on trusty

[Peder Chr. Nørgaard]

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/mono/4.5/mod-mono-server4.exe disappears from the system.

Luckily there is a good description in the apache error log:

Stacktrace:

  at <unknown> <0xffffffff>
  at Mono.WebServer.VPathToHost.CreateHost (Mono.WebServer.ApplicationServer,Mono.WebServer.WebSource) <0x0007b>
  at Mono.WebServer.ApplicationServer.GetApplicationForPath (string,int,string,bool) <0x0013f>
  at (wrapper remoting-invoke-with-check) Mono.WebServer.ApplicationServer.GetApplicationForPath (string,int,string,bool) <0xffffffff>
  at Mono.WebServer.ModMonoWorker.InnerRun (object) <0x0024f>
  at Mono.WebServer.ModMonoWorker.Run (object) <0x0001b>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

        /usr/bin/mono() [0x8105b4a]
        [0xb77bb40c]
        [0xb77bb424]
        /lib/i386-linux-gnu/libc.so.6(gsignal+0x46) [0xb75ba7e6]
        /lib/i386-linux-gnu/libc.so.6(abort+0x143) [0xb75bdc33]
        /usr/bin/mono() [0x8288b23]
        /usr/bin/mono() [0x8288bb3]
        /usr/bin/mono() [0x816b4d1]
        /usr/bin/mono(mono_class_get_full+0xff) [0x816bdff]
        /usr/bin/mono(mono_class_from_name+0x107) [0x816c237]
        /usr/bin/mono(mono_class_from_typeref+0x190) [0x816b9a0]
        /usr/bin/mono(mono_class_get_full+0x164) [0x816be64]
        /usr/bin/mono(mono_class_get+0x1f) [0x816bf4f]
        /usr/bin/mono(mono_metadata_parse_mh_full+0x45c) [0x81b29fc]
        /usr/bin/mono(mono_method_get_header+0xbf) [0x819130f]
        /usr/bin/mono() [0x807ff7c]
        /usr/bin/mono() [0x8066ccc]
        /usr/bin/mono() [0x8068de4]
        /usr/bin/mono() [0x8069aee]
        /usr/bin/mono() [0x8106d17]
        [0xb757903e]
        [0xb5816970]
        [0xb58167fc]
        [0xb5812aa8]
        [0xb58126c4]
        [0xb7466c9d]
        /usr/bin/mono() [0x8069bf0]

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-server4.exe
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-mod-mono: 2.11+git20130708.6b73e85-4ubuntu1
mono-complete: 3.2.8+dfsg-4ubuntu1
mono-apache-server2: 3.0.11-1

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

[Peder Chr. Nørgaard (pcn-2)]

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.CreateApplicationHost, to be precise, in line 150. Test output determines that the program reaches the point of this call, but the call never returns.

Now, CreateApplicationHost is part of mono, not of xsp. So I went and added an exception throw to CreateApplicationHost, 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 CreateApplicationHost is compiled as UnManagedCode? or some of the security issues around CreateApplicationHost? 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

                              --peder chr.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[shahid khan (shahid-mrd)]

I just happened to fix it kind of,by doing the following changes

i just changed /usr/lib/mono/4.0:/usr/lib to /usr/lib/mono/4.5:/usr/lib
in mono-server4-hosts.conf which you can find in /etc/mono-server4 .....

I think the problem is that assemblies required for web application are not their in /usr/lib/mono/4.0 but rather in /usr/lib/mono/4.5

[shahid khan (shahid-mrd)]

how can i help to fix this bug for all people???

[shahid khan (shahid-mrd)]

to further clarify with which distro versions and packages i encountered and fix this bug.

my mono packages versions are the same as the bug's reporter (Peder Chr. Nørgaard (pcn-2)) packages versions and i am using ubuntu 14.04 LTS

[shahid khan (shahid-mrd)]

if after this fix some of you face System.Web.HttpException , error 4 , error 5 or resource not found , just restart the apache server and you will be good to go..

[shahid khan (shahid-mrd)]

I want to put further in this after the workaround that i have given above ,every time i restarted my computer it would give me System.Web.HttpException and the apache error log would show that mono could not write to /var/www/.mono because of permissions , i did another work around and now even after restart it works fine . the work around is given below.

I changed MonoPath from /usr/lib/mono/4.5 to /usr/lib/mono/gac in etc/mono-server4/mono-server4-hosts.conf
and i manually made .mono directory at /var/www and gave apache read and write access as well as execution access to /var/www/.mono .

[Zachary Burns (zburns)]

Also package needs to be changed so it doesn't hang due to enabling mod_mono and mod_mono_auto - just give the user a choice or accept the mod_mono_auto as default. See attached screenshot.

[Zachary Burns (zburns)]

My fix was as simple as changing

/etc/mono-server4/mono-server4-hosts.conf

and setting the MonoPath line to the following (from 4.0 to 4.5)

MonoPath default /usr/lib/mono/4.5:/usr/lib

[Peder Chr. Nørgaard (pcn-2)]

Zachary, shahid, thanks for your help.

The bug is truly easy to fix in the distribution: Just change line 83 in the source file debian/mono-server4-update to use 4.5 instead of 4.0. So now

Zachary, the problem you mention with the module installs - I have had them, too (and also in ealier Ubuntu distros) but as the problem belongs to a different source package (mod_mono), we should not discuss them here. I may write a report on that problem myself one day.

I attach a patch - almost an overkill - but maybe that will prompt someone to verify the problem and solution and actually work the fix into the distribution.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "xsp_patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Brompot (ubuntubugz-vdnberg)]

The problem is that mod-mono-server4.exe in /usr/lib/mono/4.5/ is compiled against .NET 4.5 and the mod_mono config points to the .NET 4.0 libraries. The version mismatch causes the problem.

A better fix than just pointing to the 4.5 runtime would be to have a mod-mono-server4.exe in /usr/lib/mono/4.0 that is compiled against the 4.0 runtime, for thos of us who still have 4.0 applications to run. They may work on a 4.5 runtime, but the behavior may differ.

If this fix is acceptable I'll see if I can free some resources to get the fix made.

[Pankaj Garg Insan (pankajgarg-kumar41)]

i am also receive this message frequently in Apache error log when Apache server restart.Sometime when Ubuntu server restart Apache did not work.and my asp .net application stop up
Bad call to mono_mutex_lock result 22
* Assertion at image.c:1498, condition `ret == 0' not met
[:error] [pid 9749:tid 140069910509440] Failed running '/usr/bin/mod-mono-server2 --filename /tmp/mod_mono_server_global --nonstop --master (null) (null) (null) (null)