For the last few weeks, I've been hunting down the source of a bug where an old BufferedBitmap that was nulled (and should have been memory-collected) loads instead of a Bitmap from the executable that is indicated by the resource ID.
Here's what I see when it happens in the image below.
A small icon should load & paint in the area indicated by the green box.
But instead, it loads & paints a BufferedBitmap from an entirely different file in the project (highlighted in red). That's one of the historic values of the BufferedBitmap I use to cache the state of the display behind the second hand. But notice from the position of the hands in the old Buffered Bitmap that it was from about an hour ago - so it should be cleaned up long ago. I don't have any known memory references to that object in the project - the variable is only referenced about 4-5 times, and so it's easy to keep track of them.
It's supposed to look like this image below. Notice the location of the weather icon in the top mini-dial. That's what's painting a whole screen-sized buffered bitmap instead of the icon. The erroneous painting happens somewhere in the middle, that's why some of the other items layer on top (e.g. the date display).
Here are a few other details:
- This only happens on the device - I can't seem to replicate in the simulator.
- This only happens after the WF has been started and running - it will never launch into this state.
- I can now semi-reliably trigger it on the device. After the WF starts, I go into CIQ settings and swap a metric on one of the min-dials. Sometimes it'll glitch like the top image.
- Changing these settings using on-device settings does not seem to cause the same glitch like when CIQ changes the metric.
- Another cause for the glitch is when the weather condition changes (over time), and it goes to load a new icon to represent the weather. Instead of loading the new weather icon, it loads that old BufferedBitmap.
- I can get it to glitch in all 3 of the mini-dials, so it's not special to one of them.
- I have 2 other WFs that use the same architectural patterns for loading the bitmaps from the executable, and they never encounter this issue
Some environment information:
- CIQ 4.16
- Epix Gen 2 (10.46)
Architectural notes:
- The variable that holds the BufferedBitmap exists only inside my View.mc file, it's never sent as a parameter to the function where the icon loading & drawing happens.
- The resources that should load comes from Barrel A, but the call for WatchUI.loadResource() happens inBarrel B - I'm wondering if this causes glitchiness?
- There are no circular refs or other weirdness
- I'm not approaching memory limits - I actually shrunk the memory footprint down to about 83k (vs. the screenshot above from a few days ago).
What I've tried:
- I tried renaming the BufferedBitmap in case there was some weird issue - that wasn't it
- I swapped from using Application.loadResource to WatchUI.loadResource -- that didn't resolve it
- I checked the memory profile to make sure all the Rez drawables have sensible values (they do)
- I just changed the behavior to never null out the BufferedBitmap and instead just keep it, even when onHide() gets called and I try to clean up memory. That way it should never need to get cleaned up. Will report back on this...
I'm considering filing a bug, but I wanted to check here first. This seems to me like a Monkey C memory corruption issue. Does that seem right, or has anyone else seen something like this?