Bug 33996 - Bitmap.CreateBitmap - null pointer exception
Summary: Bitmap.CreateBitmap - null pointer exception
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2015-09-16 03:01 UTC by Jakub Holovsky
Modified: 2015-09-18 17:04 UTC (History)
1 user (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:

Description Jakub Holovsky 2015-09-16 03:01:01 UTC
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):

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

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




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.
Comment 1 Jonathan Pryor 2015-09-17 16:34:50 UTC
Which Android version is this?

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:


>         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,

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<T>(), 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.
Comment 2 Jakub Holovsky 2015-09-18 06:59:22 UTC
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?
Comment 3 Jonathan Pryor 2015-09-18 17:04:33 UTC
> if I remove the using statement, will it introduce a memory leak?

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 <ClasName>.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.