[Mono-dev] [ARM] Argument corruption problem

Tim Cussins timcussins at eml.cc
Tue Jan 15 14:18:08 EST 2008

Hi all!

I'm having a pretty strange issue running mono on armel, hopefully
someone can steer me in the right direction.

I've been looking at building mono for the Nokia N800, hopefully so we
can get a System.Windows.Forms based app up and running. Using the
latest releases (mono-1.2.6 & libgdiplus-1.2.6) I've successfully built
mono and libgdiplus (scratchbox). I have the resulting mono installed on
both x86 and armel versions installed inside scratchbox. On both archs,
some small in-house mono cli apps run fine.

On the N800, our Windows.Forms app fails when Form attempts to load
"mono.ico" from the resources within the System.Windows.Forms assembly.

I think I've taken Windows.Forms (somewhat) out of the picture. I have a
trivial app that reproduces the issue without using Windows.Forms. Note
that "icons.rex" is attached.

    using System;
    using System.Resources;
    using System.Reflection;
    using System.Drawing;

    class ResourceTestApp
        public static void Main()
            ResourceManager rm = new ResourceManager( "icons",
            Assembly.GetExecutingAssembly() );
            Icon i = rm.GetObject( "test.ico" ) as Icon;
            Console.WriteLine( "Icon loaded: " + i.Width + "x" +
            i.Height );

Built using:
    resgen icons.resx
    gmcs -debug restest.cs -resource:icons.resources -r:System.Drawing

The test app runs correctly on x86 inside scratchbox, and on my ubuntu
machine. However on the N800 I get the following stacktrace:

Nokia-N800-50-2:~# mono restest.exe

Unhandled Exception:
System.Runtime.Serialization.SerializationException: There are some
fixups that refer to objects that have not been registered
  at System.Runtime.Serialization.ObjectManager.DoFixups () [0x00000]
  (System.IO.BinaryReader reader) [0x00000]
  (System.IO.BinaryReader reader, Boolean readHeaders, System.Object&
  result, System.Runtime.Remoting.Messaging.Header[]& headers) [0x00000]
  (System.IO.Stream serializationStream,
  System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000]
  (System.IO.Stream serializationStream) [0x00000]
  at System.Resources.ResourceReader.ReadNonPredefinedValue (System.Type
  exp_type) [0x00000]
  at System.Resources.ResourceReader.ReadValueVer1 (System.Type type)
  at System.Resources.ResourceReader.ResourceValue (Int32 index)
  at System.Resources.ResourceReader+ResourceEnumerator.get_Value ()
  at System.Resources.ResourceSet.ReadResources () [0x00000]
  at System.Resources.ResourceSet.GetObject (System.String name, Boolean
  ignoreCase) [0x00000]
  at System.Resources.ResourceManager.GetObject (System.String name,
  System.Globalization.CultureInfo culture) [0x00000]
  at System.Resources.ResourceManager.GetObject (System.String name)
  at ResourceTestApp.Main () [0x00000]

I've rebuilt mono with some extra console output to shed some light on
how this is failing. When a resource is requested from the assembly, all
the resources are iteratively added to an objectmanager within the
ResourceManager. For each object,
reads the objectId from the binary stream representing the resources,
then passes it to
It seems the value of objectId is lost once inside the latter function
(on N800).

Here's x86 for reference:

    [sbox-CHINOOK_X86: ~/projects/restest] > mono restest.exe
    ReadObjectInstance() : objectId = 1
      ReadObjectContent() : objectId = 1
    ReadObjectInstance() : objectId = 3
      ReadObjectContent() : objectId = 3
    Icon loaded: 32x32

and N800 (armel)

    Nokia-N800-50-2:~# mono restest.exe
    ReadObjectInstance() : objectId = 1
      ReadObjectContent() : objectId = 4638811555476315824
    ReadObjectInstance() : objectId = 3
      ReadObjectContent() : objectId = 4638811555476315824

    Unhandled Exception:
    System.Runtime.Serialization.SerializationException: There are some
    fixups that refer to objects that have not been registered

The giant objectId (4638811555476315824) is not found (therefore a new
object is created), we end up with an extra object in the
ObjectManager's hashtable, and the discrepancy between hashtable objects
and registered objects causes the exception to be thrown.

Ok - the million dollar question - what's the best way to figure out
where the giant objectId comes from? Any tips on how to proceed would be
welcome :) Maybe the default stack size is not sufficient on arm? I'll
try rebuilding mono with some hacks...

Sorry about the giant post.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icons.resx
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080115/2c57c6e9/attachment.pl 

More information about the Mono-devel-list mailing list