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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xsp in Ubuntu. https://bugs.launchpad.net/bugs/1293481 Title: asp.net 4.0 with apache does not seem to work on trusty Status in “xsp” package in Ubuntu: Confirmed 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/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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xsp/+bug/1293481/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
