Memory corruption or problem with multiline strings in SPI Memory Manager

[nuschpl]

Probably picture will be worth more than hundred words so I'm attaching: The issue I'm reporting here is not SPI itself related only the GUI part which gets broken in this specific case. Namely the string Vendor id: 0x20 which should got split into two lines:

• Vendor id:
• 0x20 Actually get splits into 3 lines:
• Vendor
• i-
• d: 0x20

So I'm betting it somehow related to multiline splitting or just memory corruption. The code printing it is:

 furi_string_printf(str, "Vendor\nid: 0x%02X", spi_mem_chip_get_vendor_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 16, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));
    furi_string_printf(str, "Type\nid: 0x%02X", spi_mem_chip_get_type_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 64, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));
    furi_string_printf(str, "Capacity\nid: 0x%02X", spi_mem_chip_get_capacity_id(app->chip_info));
    widget_add_string_multiline_element(
        app->widget, 110, 44, AlignCenter, AlignBottom, FontSecondary, furi_string_get_cstr(str));

I've tried to dig into the code and guessing that this is something related to: function elements_multiline_text_aligned and its subsequent call to: size_t chars_fit = elements_get_max_chars_to_fit(canvas, horizontal, start, x); and line = furi_string_alloc_printf("%.*s-\n", chars_fit, start); where the dash char is added. But I'm unable to quickly determine if this is bug in flipper GUI logic or in the way fapp is using those GUI calls.

[skotopes]

it's not memory corruption, but incorrect text overflow handling

[nuschpl]

Yes, I've realized that in the middle of writing avove with function widget_add_string_multiline_element being good starting candidate. Maybe someone familiar with how this overflow is supposed to work can point to specific logic which might be te cause here.

[portasynthinca3]

I was able to reproduce the rendering issue with a static call for testing purposes, since I don't have access to your particular flash chip (or any other SPI flash chip, for that matter):

widget_add_string_multiline_element(
    widget, 16, 44, AlignCenter, AlignBottom, FontSecondary, "Vendor\nid: 0x20");

Update: It seems like moving the text by two pixels to the right solves the issue. #241

[nuschpl]

Just of curiosity - do we know the root cause why the moving by two pixels solves issue ? To have universal solution ?

[portasynthinca3]

Just of curiosity - do we know the root cause why the moving by two pixels solves issue ? To have universal solution ?

Yeah. Before the fix, the text drawing routine was seeing that the text overflows the screen to the left by two pixels, and was deciding to break it in the middle to avoid the overflow. By moving the text by two pixels to the right, the overflow and the consequent line break is effectively prevented. Erroneous positioning of the text is the root cause of this bug.

By the way, closing the issue because it's been solved.