Crash in GUI_ALLOC_Free during GUI_QR_Create

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Crash in GUI_ALLOC_Free during GUI_QR_Create

      Hi,

      I am using stemwin (version 5.44) on an STM32F429
      I am calling

      Source Code

      1. GUI_MEMDEV_Select(m_hMemDev);
      2. ...
      3. (*pHandle) = GUI_QR_Create( sText, nPixelSize, nEccLevel, nVersion );
      4. ...
      5. GUI_MEMDEV_Select(0);


      but sadly this triggers an exception handler.
      Looking at the program counter in the exception frame i see I am in GUI_ALLOC_Free.
      I have put a breakpoint on the offending asm line and I see i hit this point several times ( 20 -30 ?) with acceptable values, but then he tries to dereference an address 0x6901133C which is an not an existing address on my processor (see screenshot).

      Can you give me an indication how this could happen ?

      Some speculation of my own:
      I am guessing the allocs and frees happen inside of the memory block I give to stemwin via GUI_ALLOC_AssignMemory.
      At the moment i pass it a 64kb buffer, and I put a memory device in there which I use as a kind of framebuffer for my 128*160*2 bytes per pixel screen , so 40960 bytes.
      Which means about 20kb remains.
      Could it be that this is too small, that somewhere GUI_QR_Create does a malloc that fails, and that the uninitialized memory pointer then ends up in a free ?Sadly I cannot easily increase the memory size to test this hypothesis) ?

      Note: in the above code, i don't know if I need to select the memdev for creating the QR code since the 'drawing' of it only happens later, but i figured it would not harm either.

      Regards,
      Bram
      Images
      • Crash.jpg

        977.85 kB, 1,875×1,104, viewed 415 times
    • Hi,

      creating a QR code allocates memory, although they aren't very memory intensive. Basically, the function allocates memory to create a 1bpp bitmap which is the QR code. A 1bpp bitmap would have to be about 400x400px big to require 20kB of memory.

      Can you send me some code to reproduce this issue?

      Best regards,
      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Hi,
      To simplify the scenario down to the essence I replaced all the stuff I do with the following startup code and I still run into the issue:

      Source Code

      1. int DISPLAY_init( void )
      2. {
      3. GUI_MEMDEV_Handle l_hMemDev = GUI_MEMDEV_CreateEx(0,0,128,160, GUI_MEMDEV_NOTRANS);
      4. GUI_HMEM l_pHandle;
      5. // rotate
      6. LCD_SetSizeEx (0, 160, 128);
      7. LCD_SetVSizeEx(0, 160, 128);
      8. GUI_MEMDEV_Delete( l_hMemDev );
      9. m_hMemDev = GUI_MEMDEV_CreateEx(0,0,160,128, GUI_MEMDEV_NOTRANS);
      10. // QR
      11. GUI_MEMDEV_Select(l_hMemDev );
      12. l_pHandle = GUI_QR_Create( "Test", 5, 2, 20 );
      13. GUI_MEMDEV_Select(0);
      14. return( 0 );
      15. }
      Display All


      I have display.c containing this snipped together with GUIConf.c (which configures the memory area) and STemwin_wrapper.c (I don't think there is anything relevant in there but you never know there is something relevant in there) to a file located at:
      download.dekimo.be/public/BPE/QRTest.zip

      Is this sufficient code to reproduce the issue at your end or do you need something else ?

      Regards
      Bram
    • Hi,

      You should make sure that GUI_Init() is called before you use any other emWin routines. Also, I didn't see a superloop in the files you sent. It isn't crucial for the routines you are using but necessary for Window Manager related routines.

      Best regards,
      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Hi,

      GUI_Init() is called via STemwin_wrapper.c/GRAPHICS_Init()

      This happens before Freertos is started, while the DISPLAY_Init is called from a Freertos task (i hope there is no restriction there ?).


      At the moment I only use the "primitive" drawing functions, but I will keep the superloop in mind for when I need something more complex.

      Regards,

      Bram
    • Hi,

      Any updates on this ?
      Is there maybe a possibility to give me just the sources for the QR generator part so I can check here what is going on ?
      If not I think i will just use some other QR generator code and draw the matrix myself, but it is a bit stupid if the code is already present.
      (If Segger used an existing one which is available under an MIT/Apache/... license let me know then I try to use the same one and maybe learn that way what goes wrong).

      Regards
      Bram
    • Hi,

      I was able to reproduce the crash and fix the bug. The crash occurs because emWin runs out of memory. The bitmap created by the QR routine is 485x485 pixels big, because the ModuleSize is 5px and the version number is 20. A version number of 20 sets the size of the QR code to 97x97 (see here).

      BramPeeters wrote:

      l_pHandle = GUI_QR_Create( "Test", 5, 2, 20 )
      It is recommended to pass 0 as a parameter for the version number.

      The bug fix will be published with the next emWin release.

      Best regards,
      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.
    • Hi,

      Awesome, I can confirm with 0 io 20 as version it works now!
      And thanks for the version information, i just took something in the middle of the range thinking middle is good :) without really knowing what it does.

      Since it seems unlikely we will ever get a stemwin with the fix, is there a way for me to check up front how much free memory is left to block calls that would trigger the problem ? (I would have to avoid using version 0 then too otherwise I dont know how big the bitmap will be)
      Or maybe I better call a malloc/free myself of the expected memory usage and see if that works, since i not only need an amount of free memory but it needs to fit in 1 block.

      And the bitmap that is created by the QR routine, what is the memory size of a pixel there ? rgba 32bit ? Or does it take into account the final pixel size of 2 byte/pixel in my case ? Or still something else ?

      Regards
      Bram
    • Hi,

      you can receive information about emWin's memory during runtime using these routines:
      • GUI_ALLOC_GetNumFreeBytes()
      • GUI_ALLOC_GetNumUsedBytes()
      • GUI_ALLOC_GetMaxUsedBytes()
      A QR code uses a 1bpp bitmap, since there are two colors.

      By the way, the manual now also provides a formula to calculate the memory requirement of a QR code:

      Source Code

      1. NumReqBytes = (sqrt(((4 * Version) + 17) * Pixelsize) / 8) + 48

      Best regards,
      Florian
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/

      Or you can contact us via e-mail.