Function "lv_label_set_static_text" crashes with long texts


When I try to use the function “lv_label_set_static_text” using long texts, it crashes.

What MCU/Processor/Board and compiler are you using?

ARM Cortex-M4. Kinetis K22

What do you experience?

I am using the function “lv_label_set_static_text” with the long_mode: LV_LABEL_LONG_DOT for the text. The problem is that “lv_label_set_static_text” calls “lv_label_refr_text”, and it try to modify the text (replacing the last characters by dots), but the text is const, so it crashes.

What do you expect?

I think that dots should be added but the text shouldn’t be modified in this case (const text).

Screenshot and/or video

The function “lv_label_set_static_text” has a pointer to a const text as parameter.

And, in function “lv_label_refr_text”, the const text is modified.

Yes; this is definitely an issue. Nice find!

I’m not sure what the best approach to solving this is. If we allocate a buffer when using LV_LABEL_LONG_DOT it defeats the whole purpose of using lv_label_set_static_text in the first place. Maybe we shouldn’t allow use of LV_LABEL_LONG_DOT if you are using a static buffer?

Hi! Thanks for your answer.

I need this feature in my current project, so, I think that the best solution is to allocate a buffer when using LV_LABEL_LONG_DOT with lv_label_set_static_text . This buffer wuould be used only if to add dots is necessary (when the text doesn’t fit). If the text fits properly, the buffer wuouldn’t be used.

What do you think about this solution?

That would be almost entirely identical to calling lv_label_set_text with the exact same arguments, hence why I suggested disallowing the use of LV_LABEL_LONG_DOT only with lv_label_set_static_text. Otherwise the name static_text becomes misleading since the static buffer is only used directly in some situations.

OK, in this case the best solution to solve the problem would be your proposal: shouldn’t allow to use of 'LV_LABEL_LONG_DOT` if you are using a static buffer.


What would be the best way of blocking this from a user’s perspective? I’m thinking the following:

  • When lv_label_set_static_text is called with LV_LABEL_LONG_DOT, set the text, but change the long mode to something else. Or, possibly even set the text to something short and informative like “Error: see docs on LONG_DOT”.
  • Add a note in the documentation that LV_LABEL_LONG_DOT does not work with lv_label_set_static_text.
  • Log a warning in the debug log (if it’s enabled).

Do you think that would convey the message well enough that someone wouldn’t have to debug for long to find the problem?

There are 2 cases:

  1. LONG_DOT is already set and lv_label_set_static_text is called. What to do in this case? Change the long mode to LONG_EXPAND automatically?
  2. static text is set and lv_label_set_long_mode with LONG_DOT. In this case, the function can return without doing anything.

We should display log warnings in both cases.

These would definitely useful.

Exactly. I can fix it today or tomorrow; should I apply it to master or dev-7.0? I would think master since it’s clearly broken anyways, but I’m just checking. :slightly_smiling_face:

I agree with you but, besides, I think that it would be useful to have a function to check if the text fits or not. The user (who is using LV_LABEL_LONG_DOT mode) can check in his app if the text fits using this function. If it fits, he can select lv_label_set_static_text, if it doesn’t fit, he has to use lv_label_set_text.

Obviously, the user must have knowledge of the specifications above discussed.

Regards! :slight_smile:

If the text fits, the exact long mode chosen doesn’t matter, because long modes only come into play when the text no longer fits. Therefore, they would see no visual difference. In the event that it doesn’t fit, we still need a fallback for if the user calls lv_label_set_static_text.

I agree with your logic, but I don’t see a need (or use case) for the extra function. Are you suggesting that they would have to test each of their strings to see if it fit? That seems quite ugly and not worth it. Maybe I’m misunderstanding something.

I agree it can go to master.

So what would be the behavior?
If we are in DOTS mode and a too long test is passed to lv_label_set_static_text():

  1. Ignore DOTS mode and change to EXPAND?
  2. Ignore static behavior and allocate the text?
1 Like

It would be option #1. Option #2 is identical to calling lv_label_set_text, which is less intuitive than just ignoring the long mode (I think).

I also prefer #1.
#2 would cause a huge memory allocation what user probably want to avoid.

I was thinking about this some more. There is nothing wrong with the use of lv_label_set_static_text itself; the problem is with the constant buffer passed to it. As long as the buffer is RW, everything should work fine (the buffer will temporarily be modified by the label and restored).

That’s true. The buffer is not necessarily const.
Do have any suggestions in light of that? Leave it as it is and let the user take care of this possible conflict? (Add note to the docs and comment of course.)

Yes. I committed a change to the docs repository the other day that addresses this. But I don’t think anything in the implementation needs to change. The user should just be aware of this problem, and use lv_label_set_text if they really want to use a constant buffer (although, since it allocates a new buffer anyways, it makes no difference in the end).

Okay, I agree.