Fixed crash

The problem lies in a change in the second SDK release. The second SDK
release aggressively GC’s all unused code and also no longer
0-initializes variables. The GC was a welcome change, it unlocked
around 9KB more code space for app developers. Now that’s odd, you
might be thinking that you didn’t even need to comment out line 17 then
if the GC removes unused code. That’s right, you’ll find out that the
binary size (build/pebble-app.bin) is the same whether or not you
comment it out. The question is why does it crash?

That’s a combination of the compiler and runtime environment. Because
there is no longer any 0-initialization, the variables could start out
with anything. It just turns out that commenting out line 17 causes the
compiler to build the app in such a way that if it were to run in the
Pebble, date_digits_images[0] will be filled with bad garbage data.

How is the garbage data bad? We don’t recommend developers to use
layer_remove_from_parent and bmp_deinit_container on variables that are
uninitialized, especially if they are used on variables with garbage
data. Operations on garbage data could lead to the Pebble performing
operations on addresses of memory it shouldn’t and cause a crash.
They’re only safe when used with either initialized variables
(layer_init, bmp_init_container) or variables that have been deinited.

Fortunately however, we usually deinit variables by setting pointers to
NULL and make sure we use operations that accept NULL, so a simple fix
is to 0-initialize variables yourself and then you’re free to remove or
deinit first before init. This should fix your issue:

void handle_init(AppContextRef ctx) {
    memset(&background_image, 0, sizeof(background_image));
    memset(&day_name_image, 0, sizeof(day_name_image));
    memset(&date_digits_images, 0, sizeof(date_digits_images));
    memset(&time_digits_images, 0, sizeof(time_digits_images));
    memset(&digits, 0, sizeof(digits));
    memset(&display_layer, 0, sizeof(display_layer));

    …
}