[ubuntu-mono] [Bug 1293481] [NEW] asp.net 4.0 with apache does not seem to work on trusty

Mon Mar 17 10:11:46 UTC 2014

Public bug reported:

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

** Affects: xsp (Ubuntu)
     Importance: Undecided
         Status: New

** Tags: asp.net mono trusty xsp

** Attachment added: "tar file with a very small ASP.NET application"
   https://bugs.launchpad.net/bugs/1293481/+attachment/4028108/+files/sample.tar

-- 
You received this bug notification because you are a member of Ubuntu
CLI/Mono Uploaders, 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> <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