Android - Bitmap.CreateBitmap - null pointer exception

Question

Sometimes when I am trying to create blurred bitmap I am getting "Null Pointer Exception".

Happens in this block of code (I recently started catching the exception so at least it doesn't crash the app):

try
{
    using (Bitmap.Config config = Bitmap.Config.Rgb565) {
        return Bitmap.CreateBitmap (blurredBitmap, width, height, config);
    }
}
catch (Java.Lang.Exception exception)
{
    Util.Log(exception.ToString());
}

Please refer to these pictures for more details about parameters I am passing into the "CreateBitmap" method:

Here is the expanded parameters:

Full exception:

exception {Java.Lang.NullPointerException: Exception of type 'Java.Lang.NullPointerException' was thrown. at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000b] in /Users/builder/data/lanes/2058/58099c53/source/mono/mcs/class/corlib/System.Runtime.ExceptionServices/ExceptionDispatchInfo.cs:61 at Android.Runtime.JNIEnv.CallStaticObjectMethod (IntPtr jclass, IntPtr jmethod, Android.Runtime.JValue* parms) [0x00064] in /Users/builder/data/lanes/2058/58099c53/source/monodroid/src/Mono.Android/src/Runtime/JNIEnv.g.cs:1301 at Android.Graphics.Bitmap.CreateBitmap (System.Int32[] colors, Int32 width, Int32 height, Android.Graphics.Config config) [0x00088] in /Users/builder/data/lanes/2058/58099c53/source/monodroid/src/Mono.Android/platforms/android-22/src/generated/Android.Graphics.Bitmap.cs:735 at Psonar.Apps.Droid.PayPerPlay.StackBlur.GetBlurredBitmap (Android.Graphics.Bitmap original, Int32 radius) [0x00375] in d:\Dev\psonar\Source\Psonar.Apps\Psonar.Apps.Droid\Psonar.Apps.Droid.PayPerPlay\Utilities\StackBlur.cs:123 --- End of managed exception stack trace --- java.lang.NullPointerException at android.graphics.Bitmap.createBitmap(Bitmap.java:687) at android.graphics.Bitmap.createBitmap(Bitmap.java:707) at dalvik.system.NativeStart.run(Native Method) } Java.Lang.NullPointerException

Not sure if this could be a bug in Xamarin or the passed parameters are wrong.

Answer 1

I got a reply from one of the members of the Xamarin team - Jonathan Pryor:

The NullPointerException is coming from Java code:

at android.graphics.Bitmap.createBitmap(Bitmap.java:687) at android.graphics.Bitmap.createBitmap(Bitmap.java:707) at dalvik.system.NativeStart.run(Native Method)

Looking quickly at a variety of releases, Jelly Bean might fit:

https://github.com/android/platform_frameworks_base/blob/jb-release/graphics/java/android/graphics/Bitmap.java#L687

    return nativeCreate(colors, offset, stride, width, height,
                        config.nativeInt, false);

A quick glance at the surrounding method body shows that config isn't checked for null-ness, so if null is passed this would result in a NullPointerException.

The problem, though, is that you're not passing null:

using (Bitmap.Config config = Bitmap.Config.Rgb565) {
    return Bitmap.CreateBitmap (blurredBitmap, width, height, config);
}

...or are you?

I would suggest that you remove the using block:

return Bitmap.CreateBitmap (blurredBitmap, width, height,
        Bitmap.Config.Rgb565);

Here's what I think may be happening, but first, a digression:

Deep in the core of Xamarin.Android there is a mapping between Java objects and their corresponding C# wrapper objects. Constructor invocation, Java.Lang.Object.GetObject(), etc. will create mappings; Java.lang.Object.Dispose() will remove mappings.

A core part of this is Object Identity: when a Java instance is exposed to C# code and a C# wrapper is created, the same C# wrapper instance should continue to be reused for that Java instance.

An implicit consequence of this is that any instance is effectively global, because if multiple code paths/threads/etc. obtain a JNI handle to the same Java instance, they'll get the same C# wrapper.

Which brings us back to my hypothesis, and your code block: Bitmap.Config is a Java enum, meaning each member is a Java object. Furthermore, they're global values, so every thread has access to those members, meaning the C# Bitmap.Config.Rgb565 instance is effectively a global variable.

A global variable that you're Dispose()ing.

Which is "fine", in that the next time Bitmap.Config.Rgb565 is access, a new wrapper will be created.

The problem, though, is if you have multiple threads accessing Bitmap.Config.Rgb565 at the ~same time, each of which is trying to Dispose() of an instance. At which point it's entirely plausible that the two threads may reference the same wrapper instance, and the Dispose() from one thread will thus INVALIDATE the instance used by the other thread.

Which would result in null being passed to the Bitmap.createBitmap() call, which is precisely what you're observing.

Please try removing the using block, and see if that helps matters.

The whole thread is accessible here.

Then I asked:

Jonathan Pryor - cheers for the suggestion. My question is that if I remove the using statement, will it introduce a memory leak? Meaning if I stop disposing the new config instance?

He replied:

That's what GC's are for!

(insert coughing and laughter here.)

We can quibble quite a bit. I'll argue that it is NOT a memory leak, because the memory is well rooted and well known; constantly accessing the Bitmap.Config.Rgb565 will return the previously created instance, not constantly create new instances. There is no "leak," as such.

I'll instead argue that the instance, and the underlying GREF, is a "tax"; it's "burnt", part of the cost of doing business. While it would be "nice" to minimize these costs, it isn't practical to remove all of them (e.g. we "lose" a GREF per class via .class_ref, which is used to lookup method IDs...), at least not with the current architecture.

(I also can't think of an alternate architecture that would result in different costs/"taxes". While I do have some thoughts on allowing things to be improved for some areas, they're not huge.)

I would suggest not worrying about Bitmap.Config.Rgb565 and similar members too much, unless/until the profiler or GREF counts show otherwise.