"Local Variable" view shows garbage values for uninitialized local variables (potential UX issue)

[georgewsinger]

In a trace, I have a function with local variable fmt which isn't immediately defined:

    bool WlrGLES3Texture::wlr_texture_write_pixels(
        struct wlr_texture *_texture, uint32_t stride,
        uint32_t width, uint32_t height,
        uint32_t src_x, uint32_t src_y, uint32_t dst_x, uint32_t dst_y,
        const void *data) {
      //..
      const struct gles3_pixel_format *fmt = gles3_texture->pixel_format;
      //..
    }

When clicking on an execution of this function and opening the "Local Variables" view, Pernosco shows a bunch of garbage data in fmt. This tripped me up for a while (longer than I want to admit!) until I realized it was just uninitialized state that was showing garbage values.

Pernosco shows the same garbage data values in GDB when you i.e. print fmt at the function break; however, if you step a few lines down it will eventually show the correct value through the GDB view. Contrasting with rr: when I try to print uninitialized local variables in rr I get, i.e., "Cannot access memory at address 0x3f8000003f80000".

It might be a useful feature to somehow flag that the state being showed is uninitialized and/or show the eventual definition of a value cleverly somehow.

[khuey]

Thanks for reporting this. It is indeed confusing behavior.

The cause of this is that in an unoptimized debug build the compiler will set aside a stack slot for the variable throughout the entire function lifetime, and emit corresponding debug info, despite the variable not yet being live at the beginning of the function. We need to also check the line numbers (as gdb does) to see if we've reached the right line before including the variable in the locals view (or rendering it without an uninitialized flag or something).

[khuey]

For now we'll just not show these variables. That will be deployed tomorrow.

[khuey]

Deployed.