[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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) -- 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 0x 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) 0x 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) 0x 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] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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 0x 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) 0x 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) 0x 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:
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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. ** Attachment added: xsp_patch https://bugs.launchpad.net/ubuntu/+source/xsp/+bug/1293481/+attachment/4112221/+files/xsp_patch -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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.] ** Tags added: patch -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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. ** Attachment added: SNAG-4-22-2014-14-08-18.png https://bugs.launchpad.net/ubuntu/+source/xsp/+bug/1293481/+attachment/4092940/+files/SNAG-4-22-2014-14-08-18.png -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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 -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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 . -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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.. -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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 -- 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 0x 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) 0x 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) 0x 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 :
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
how can i help to fix this bug for all people??? -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
I think the bug has nothing to do with xsp it is the mis configuration of the mono_server4 i tested the fix on ubuntu 14.04 LTS trusty (final release on 17 april) . The stack trace also shows that when mono-mono server ask mono to compile the asp.net page, mono can not find the classes that are needed because it looks for them in /usr/lib/mono/4.0 which are not their.. This is what i think. may be i am wrong but i worked for me. -- 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 0x 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) 0x 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) 0x 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] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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 -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: xsp (Ubuntu) Status: New = Confirmed -- 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 0x 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) 0x 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) 0x 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
[Desktop-packages] [Bug 1293481] Re: asp.net 4.0 with apache does not seem to work on trusty
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. -- 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: New 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 0x 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) 0x 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) 0x 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
