App is now with QA to retest, will have results soon, so I will let you know.
-Pavel Sent from my iPhone 4S On Dec 7, 2011, at 23:43, Sebastien Pouliot <[email protected]> wrote: > Hello Pavel, > > With a bit of IL (since C# is a bit restrictive when throwing things) > I was able to duplicate the same crash/assert you had. Once I added > the workaround try/catch code the exception was catched, as expected - > i.e. without a crash. > > I'll fix the next releases of MonoTouch to cover this case properly. > Please confirm to me that it does work in your case too! > > Thanks! > Sebastien > > On Wed, Dec 7, 2011 at 3:15 PM, Pavel Sich <[email protected]> wrote: >> So thanks to the great guys (Sebastien and Rodrigo) at Xamarin there seems >> to be a fix for this issue, which looks like linker issue - stripping out >> the part of the framework that is not used directly but might be introduced >> during the DataContract use and subsequent exception in it. If proved in the >> QA process, will inform you about the outcome so you can make a note for >> that particular type of exceptions inside mono runtime. >> >> --- >> >> Hello Pavel, >> >> You're right there's no public constructor to simply create an >> instance. Also tThe `WrappedException` property expose a field that is >> shared with the runtime and it will need to be present (not linked >> out) in managed code. Something like this: >> >> try { >> } >> catch (RuntimeWrappedException rwe) { >> Console.WriteLine (rwe.WrappedException); >> } >> >> should do the trick (i.e. satisfy the runtime/managed contract). >> >> Sebastien >> >> On Wed, Dec 7, 2011 at 1:30 PM, Pavel Sich <[email protected]> wrote: >> - Hide quoted message - >> >> Will do and will update the Monotouch list then. >> >> Also class RuntimeWrappedException >> >> has no constructors defined (at least compiler says so). So what I did is >> that I explicitly catch the exception in try catch block (which was catching >> Exception objects) and use that in writing it to console output (so it is >> being used) and marked the method as Preserve. >> >> Is this correct approach then? >> >> -- >> Pavel Sich >> @sichy >> >> On Wednesday, December 7, 2011 at 7:22 PM, Sebastien Pouliot wrote: >> >> Hey, >> >> Please always c.c. the mailing-list when you reply. Right now no one >> else with a similar issue will be able to google any solution in the >> future. >> >> Pavel, if you don't mind could you c.c. this back to the list and >> edit/remove your code or anything else that could be sensitive to you. >> >> Rodrigo, yes the method would work (with any linker setting) to ensure >> the RuntimeWrappedException type is not removed by the linker. If this >> is confirmed (as the fix) I can add this rule to the linker (so it >> won't be needed in the future). >> >> Note that something is triggering this exception, from time to time, >> and the application needs to handle this (or it will fail with a >> different error). IOW this would fix the present crash, not the >> intermittent problem with the application. >> >> Sebastien >> >> On Wed, Dec 7, 2011 at 1:05 PM, Rodrigo Kumpera <[email protected]> wrote: >> >> Hi Pavel, >> >> I believe the issue is >> that System.Runtime.CompilerServices.RuntimeWrappedException is been linked >> away. >> >> To resolve that, I believe you can add the following to your main class: >> >> [Preserve] >> static void Foo () { >> new System.Runtime.CompilerServices.RuntimeWrappedException (); >> } >> >> Sebastien, is that the right idiom for such things? >> >> Regards, >> Rodrigo >> >> >> -- >> Pavel Sich >> @sichy >> >> On Wednesday, December 7, 2011 at 7:52 PM, Sebastien Pouliot wrote: >> >> Hello Pavel, >> >> You're right there's no public constructor to simply create an >> instance. Also tThe `WrappedException` property expose a field that is >> shared with the runtime and it will need to be present (not linked >> out) in managed code. Something like this: >> >> try { >> } >> catch (RuntimeWrappedException rwe) { >> Console.WriteLine (rwe.WrappedException); >> } >> >> should do the trick (i.e. satisfy the runtime/managed contract). >> >> Sebastien >> >> On Wed, Dec 7, 2011 at 1:30 PM, Pavel Sich <[email protected]> wrote: >> - Hide quoted message - >> >> Will do and will update the Monotouch list then. >> >> Also class RuntimeWrappedException >> >> has no constructors defined (at least compiler says so). So what I did is >> that I explicitly catch the exception in try catch block (which was catching >> Exception objects) and use that in writing it to console output (so it is >> being used) and marked the method as Preserve. >> >> Is this correct approach then? >> >> -- >> Pavel Sich >> @sichy >> >> On Wednesday, December 7, 2011 at 7:22 PM, Sebastien Pouliot wrote: >> >> Hey, >> >> Please always c.c. the mailing-list when you reply. Right now no one >> else with a similar issue will be able to google any solution in the >> future. >> >> Pavel, if you don't mind could you c.c. this back to the list and >> edit/remove your code or anything else that could be sensitive to you. >> >> Rodrigo, yes the method would work (with any linker setting) to ensure >> the RuntimeWrappedException type is not removed by the linker. If this >> is confirmed (as the fix) I can add this rule to the linker (so it >> won't be needed in the future). >> >> Note that something is triggering this exception, from time to time, >> and the application needs to handle this (or it will fail with a >> different error). IOW this would fix the present crash, not the >> intermittent problem with the application. >> >> Sebastien >> >> On Wed, Dec 7, 2011 at 1:05 PM, Rodrigo Kumpera <[email protected]> wrote: >> >> Hi Pavel, >> >> I believe the issue is >> that System.Runtime.CompilerServices.RuntimeWrappedException is been linked >> away. >> >> To resolve that, I believe you can add the following to your main class: >> >> [Preserve] >> static void Foo () { >> new System.Runtime.CompilerServices.RuntimeWrappedException (); >> } >> >> Sebastien, is that the right idiom for such things? >> >> Regards, >> Rodrigo >> >> >> >> _______________________________________________ >> MonoTouch mailing list >> [email protected] >> http://lists.ximian.com/mailman/listinfo/monotouch >> _______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
