I have added FreeType 2.13.2 to my code and test run in Windows PC and it looks working fine. After move the same code to ESP32, reset exception happened, I try to location to problem and finally I found one of my display string (global 50byte char variable) is being corrupted after first calling to FT_Render_Glyph(), if I skip this API call everything goes fine and no exception. This is quite basic key function of FreeType that I just cannot drop it to avoid the problem, anyone experience the same/similar when using FreeType?
It is just weird that FT_Render_Glyph works fine in Windows PC but not in ESP32, compiler flags are almost the same except std=C99 (in PC) and std=gnu17 (in ESP32). The FT_Render_Glyph is not having any parameter that related to my global variable address, and it is suppose only operates her own face->glyph data, my global variable location is quite close to the face variable according to the .map file.
.bss.menustring
0x000000003fca2de0 0x32 esp-idf/main/libmain.a(mymain.c.obj)
0x000000003fca2de0 menustring
.bss.face 0x000000003fca2e18 0x4 esp-idf/main/libmain.a(mymain.c.obj)
0x000000003fca2e18 face
.bss.library 0x000000003fca2e1c 0x4 esp-idf/main/libmain.a(mymain.c.obj)
0x000000003fca2e1c library
below is the code snippet of problem detected when calling FT_Render_Glyph(), variable 100% corrupted after 1st call the FT_Render_Glyph().
void showchar(char *textmsg)
{
uint32_t glyph_index;
glyph_index = FT_Get_Char_Index( face, *textmsg );
// ESP_LOGI(TAG, "Showchar: do nothing just return, FT_Get_Char_Index returns %"PRIu32" for char %c", glyph_index, *textmsg);
// return;
if( glyph_index == 0 )
{
ESP_LOGI(TAG, "Showchar: FT_Get_Char_Index returns 0 for char %c", *textmsg);
return;
}
if( FT_Load_Glyph(face, glyph_index, 0) )
{
ESP_LOGI(TAG, "Showchar: FT_Load_Glyph returns error for index %"PRIu32"", glyph_index);
return;
}
// ESP_LOGI(TAG, "Showchar: do nothing just return, FT_Get_Char_Index returns %"PRIu32" for char %c", glyph_index, *textmsg);
// return;
if( FT_Render_Glyph(face->glyph, FT_RENDER_MODE_NORMAL) )
{
ESP_LOGI(TAG, "Showchar: FT_Render_Glyph returns error");
return;
}
ESP_LOGI(TAG, "Showchar: do nothing just return, FT_Get_Char_Index returns %"PRIu32" for char %c, FT_Load_Glyph & FT_Render_Glyph returns 0", glyph_index, *textmsg);
return;
still not yet found a solution for this
Thanks all for responding this post. I try to build a small program of printing pages of string in both Windows and ESP32 to see whether able to trigger the same problem. The small program runs perfectly in Windows (same as FreeType integrated my original application in Windows), but it runs to unexpected result in ESP32 (as this is a thin program, it does not reset on corruption but still shows the same problem of memory corruption), it stopped at the 2nd page and loop again(due to I reload the string at start of the loop).
the marco
PCsimulatoris the main switch to building Windows or ESP32.since there are 3 main FreeType API I have to call for printing every characters, I just print my string content after each call to see any memory corruption happen, and in ESP32, the corruption happen when calling
FT_Render_Glyphfor character K, you can see the string content is totally changed, from this test result, I would certify FreeType rendering API is having serious memory corruption problem when compile to ESP32 (I cannot say it is a bug as it do works in Windows, it only not working as expected in ESP32, may be RISC-V CPU too).Any other open source library recommended to replace FreeType? (I want to use scalable TTF at my project)
OK, let's look at ESP tracelog:
you can see when doing character K, the String content is corrupted after calling
FT_Render_Glyph, this is exactly the same as my original application, the same thing happen after calling this API, and due to program size differences, it may not immediately trigger a reset, but memory corruption now confirmed not due to other part of my program, it MUST be due toFT_Render_GlyphAPI as it is 100% duplicated in this thin program. I put the source code below by removing the TTF font which 3000line of data code.