[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]
at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject
(System.IO.BinaryReader reader) [0x00000]
at
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph
(System.IO.BinaryReader reader, Boolean readHeaders, System.Object&
result, System.Runtime.Remoting.Messaging.Header[]& headers) [0x00000]
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize
(System.IO.Stream serializationStream,
System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000]
at
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize
(System.IO.Stream serializationStream) [0x00000]
at System.Resources.ResourceReader.ReadNonPredefinedValue (System.Type
exp_type) [0x00000]
at System.Resources.ResourceReader.ReadValueVer1 (System.Type type)
[0x00000]
at System.Resources.ResourceReader.ResourceValue (Int32 index)
[0x00000]
at System.Resources.ResourceReader+ResourceEnumerator.get_Value ()
[0x00000]
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)
[0x00000]
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,
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectInstance()
reads the objectId from the binary stream representing the resources,
then passes it to
System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectContent().
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
...etc...
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.
Cheers,
Tim
-------------- 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