I have found what looks like a bug involving the n...

# kotlin-native

[napperley]

I have found what looks like a bug involving the new memory model, and C String arrays. Here is the project (doesn't contain the line that causes the bug): https://gitlab.com/napperley/lvgl-hello/-/tree/keypad-encoder

The bug revolves around freeing memory after calling a function from a C library (LVGL - https://lvgl.io/ ). When starting the program a message box appears containing two buttons. The first button has no text, but the second button contains some text (Cancel). If the memory isn't freed then the first button contains some text (Ok).

Appending the following line to src/linuxArm32HfpMain/kotlin/main.kt file after line 180 ( https://gitlab.com/napperley/lvgl-hello/-/blob/keypad-encoder/src/linuxArm32HfpMain/kotlin/main.kt#L180 ) causes the bug to occur: tmpArena.clear()

[Alexander Shabalin [JB]]

Hi, thanks for trying out the new MM! Could you please clarify? Is this what happens: if tmpArena.clear() line isn't present, then two buttons with "Ok" and "Cancel" are displayed; and if tmpArena.clear() is present right after the call to lv_msgbox_create then two buttons are still displayed, but the first one doesn't have any text.

[Alexander Shabalin [JB]]

So, if that's the case, I believe it's use-after-free. It seems lv_msgbox_create just stores the contents of the btn_txts pointer without copying its contents and then accesses it during drawing (1 2 3). So, if the memory behind btn_txts pointer is freed before msgbox is gone, use-after-free happens. This means, you cannot call tmpArena.clear() until msgbox is closed.

[napperley]

I have put the tmpArena.clear() line into the body of messageBoxCallback function, and the issue doesn't occur 😄 . Was expecting a segmentation fault with the use after free issue. Quite unexpected that the program would continue to run.

[Alexander Shabalin [JB]]

Was expecting a segmentation fault with the use after free issue.

Segmentation fault is literally the best case scenario of use-after-free. Generally speaking, after use-after-free the program may behave in an entirely unpredictable fashion. If at all possible, try to use valgrind's memcheck when you suspect use-after-free or similar invalid memory access issues. The usage is quite straightforward: valgrind --leak-check=no <path to the executable>. Fair warning: it considerably slows down the execution.