[MonoTouch] Very weird crash

[Pavel Sich]

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 <sebastien at xamarin.com> 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 <pavel.sich at me.com> 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 <pavel.sich at me.com> 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 <kumpera at xamarin.com> 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 <pavel.sich at me.com> 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 <kumpera at xamarin.com> 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
>> MonoTouch at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monotouch
>>