Bug 15557 - getter for Typeface.Style throwing an unhandled exception.
Summary: getter for Typeface.Style throwing an unhandled exception.
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: 4.8.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2013-10-21 14:26 UTC by Jon Goldberger [MSFT]
Modified: 2017-07-01 01:15 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Comment 1 Jon Goldberger [MSFT] 2013-10-21 14:27:13 UTC
We are experiencing an urgent issue in our newly deployed software, which crashes on the Samsung Galaxy S4 (but all other devices are fine). The splash screen appears for a moment, but just at the instant where our actual UI would appear, the app exits. We have not been able to reproduce this ourselves as we do not have one of these devices. Our normal crash logging code does not appear to be running, indicating that this is not a managed exception of any kind.

Please, are you aware of any issue with binaries produced by Xamarin.Android running on these devices?

Our customer installed the Android debugging tools in order to obtain the logcat output. Without that, we would have been guessing for days, and it would have cost us a fortune. I have attached the log below.

Basically, we changed the font we use from “Droid Sans” to “sans-serif” for the problematic release. The problematic method in our code is one that takes an existing font and modifies it to make it smaller to ensure that text fits in a particular rectangle (we do all our own custom drawing). The exception was occurring in the getter for Typeface.Style, as you can see. One of the test releases we sent to our customer wrapped the entire WelcomeView.Draw method in a try/catch, which did not help, and it’s that fact which makes me worry about the tools here. Why didn’t a managed exception handler catch this? Should Typeface.Style be throwing at all?


E/mono-rt ( 7579): Stacktrace:
E/mono-rt ( 7579):
E/mono-rt ( 7579): at <unknown> <0xffffffff>
E/mono-rt ( 7579): at (wrapper managed-to-native) object.wrapper_native_0x40860795 (intptr,intptr,intptr) <0xffffffff>

E/mono-rt ( 7579): at Android.Runtime.JNIEnv.CallIntMethod (intptr,intptr) <0x00047>
E/mono-rt ( 7579): at Android.Graphics.Typeface.get_Style () <0x000b7>
E/mono-rt ( 7579): at Divelements.SkyDemon.Drawing.IndependentText.DrawTextToFit (Divelements.SkyDemon.Drawing.Drawing
ements.SkyDemon.Drawing.TextVAlign,System.Drawing.Color,System.Drawing.Color) <0x000d3>
E/mono-rt ( 7579): at Divelements.SkyDemon.WelcomeView.Draw (Android.Graphics.Canvas) <0x0047f>
E/mono-rt ( 7579): at Android.Views.View.n_Draw_Landroid_graphics_Canvas_ (intptr,intptr,intptr) <0x0005b>
E/mono-rt ( 7579): at (wrapper dynamic-method) object.9266793f-b32a-4ed3-a0c3-865a137e8b1b (intptr,intptr,intptr) <0x0
E/mono-rt ( 7579): at (wrapper native-to-managed) object.9266793f-b32a-4ed3-a0c3-865a137e8b1b (intptr,intptr,intptr) <
E/mono-rt ( 7579):
E/mono-rt ( 7579): =================================================================
E/mono-rt ( 7579): Got a SIGSEGV while executing native code. This usually indicates
E/mono-rt ( 7579): a fatal error in the mono runtime or one of the native libraries
E/mono-rt ( 7579): used by your application.
E/mono-rt ( 7579): =================================================================
E/mono-rt ( 7579):
Comment 2 Jonathan Pryor 2013-10-22 21:58:13 UTC
Stack traces resembling:

> E/mono-rt ( 7579): Stacktrace:
> E/mono-rt ( 7579):
> E/mono-rt ( 7579): at <unknown>
> E/mono-rt ( 7579): at (wrapper managed-to-native) object.wrapper_native_0x40860795 (intptr,intptr,intptr)]
> E/mono-rt ( 7579): at Android.Runtime.JNIEnv.CallIntMethod (intptr,intptr)

are usually caused by invoking an instance member on an instance which has a .Handle property value of IntPtr.Zero. This in turn can be due to a GC bug or programmer mistake/maliciousness:

    var o = new Java.Lang.Object();
    o.ToString(); // BOOM

The Xamarin.Android 4.10 release implements better JNIEnv argument checking and will not pass null instances to JNIEnv methods.

TL;DR: Please try running on the 4.10.0 alpha, or provide a testcase.
Comment 3 Chris Hardy [MSFT] 2017-07-01 01:15:48 UTC
Because we have not received a reply to our request for more information we are closing this issue. If you are still encountering this issue, please reopen the ticket with the requested information. Thanks!