[Mono-dev] 'Interesting' difference between ARM and x86

[Jon Shemitz]

Mono 2.4.2.

Linux OS Version: Unix 2.6.24.7

ARM, /proc/cpuinfo:

Processor       : ARMv7 Processor rev 3 (v7l)

BogoMIPS        : 499.92

Features        : swp half thumb fastmult vfp edsp 

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x1

CPU part        : 0xc08

CPU revision    : 3

Cache type      : write-through

Cache clean     : not required

Cache lockdown  : not supported

Cache format    : Unified

Cache size              : 768

Cache assoc             : 1

Cache line length       : 8

Cache sets              : 64

Hardware        : OMAP3 Beagle board

Revision        : 3430130f

Serial          : 0000000000000000

 

________________________________

From: Zoltan Varga [mailto:vargaz at gmail.com] 
Sent: Thursday, August 20, 2009 4:18 PM
To: Jon Shemitz
Cc: Mono-devel-list
Subject: Re: [Mono-dev] 'Interesting' difference between ARM and x86

 

Hi,

  I can't reproduce this using mono SVN HEAD. What mono version are you
using and on
what device/os ?

             Zoltan

On Thu, Aug 20, 2009 at 11:51 PM, Jon Shemitz
<Jon.Shemitz at access-company.com> wrote:

So far, I have been very pleasantly surprised at how much Mono on ARM
acts just like .NET on Windows. But, I've been writing some NUnit tests
as I develop a library, and have found that it seems like every Assert
failure leads to

ERROR:class.c:3324:mono_class_setup_vtable_general: assertion failed:
(cur_slot == class->vtable_size)

Stacktrace:

  at NUnit.Core.TestMethod.RecordException
(System.Exception,NUnit.Core.TestResult) <0xffffffff>

  at NUnit.Core.TestMethod.RecordException
(System.Exception,NUnit.Core.TestResult) <0x00088>

Native stacktrace:

        mono [0xe0f48]

        [0x41773df4]

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.

=================================================================

Aborted

This has been annoying (and a bit worrisome - what if this is just a
symptom of some underlying weakness? Can I seriously propose that it
would be a good idea to teach our app guys C#?) but I've been inclined
to give Mono the benefit of the doubt, as NUnit does use all sorts of
security and isolation features that my wrapper library does not.
Yesterday, though, I was working at home, without ARM hardware, and ran
my tests in our simulator, running User Mode Linux on an x86. Assert
failures worked just fine!

Now, the kernel versions do vary between the ARM ("OS Version: Unix
2.6.24.7") and x86 UML ("OS Version: Unix 2.6.22.18") environments, but
the assertion failure in class.c sort of suggests that there's some
problem in either the ARM jitter or in the hardware-specific parts of
the CLR itself. ("CLR Version: 2.0.50727.1433 ( Mono 2.4.2 )")

Is this a known issue, or should I go ahead and log it with bugzilla? If
it is a known issue, are there any environment variables or mono
switches that mitigate it?

// Minimal test case:

using NUnit.Framework;

 

[TestFixture]

public class NunitCrash

{

    [Test]

    public void AssertionFailure()

    {

        Assert.AreEqual(1, 2);

    }

}

// crashes, just like tests that use glib-sharp and my wrapper library.


_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090820/ff98aad5/attachment.html