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.
