when malloc fails allocation, it doesn't return NULL.

Hello All

If malloc fails to allocate memory, It doesnt return NULL

I don't use SDRAM , but it returns an unusable address starting with 0x96 ****** rather than a HEAP area as shown below.

This part causes a lot of problems in debugging or actual operation.

 

[2018-07-19 09:42:35.847] [CLP_ERR] hjw 1-1 aaa size only 4 i=4 alloc get bad ptr ok no free aa=0x20029208 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.847] [CLP_ERR] hjw 1-1 aaa size only 4 i=5 alloc get bad ptr ok no free aa=0x200291f8 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.847] [CLP_ERR] hjw 1-1 aaa size only 4 i=6 alloc get bad ptr ok no free aa=0x200291e8 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.847] [CLP_ERR] hjw 1-1 aaa size only 4 i=7 alloc get bad ptr ok no free aa=0x20029258 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.848] [CLP_ERR] hjw 1-1 aaa size only 4 i=8 alloc get bad ptr ok no free aa=0x96e7c0c8 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.853] [CLP_ERR] hjw 1-1 aaa size only 4 i=9 alloc get bad ptr ok no free aa=0x96e7c0b8 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.853] [CLP_ERR] hjw 1-1 aaa size only 4 i=10 alloc get bad ptr ok no free aa=0x96e7c0b0 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

[2018-07-19 09:42:35.853] [CLP_ERR] hjw 1-1 aaa size only 4 i=11 alloc get bad ptr ok no free aa=0x96e7c0a0 &aa=0x1ffed294  (mbedtls_mpi_grow:168)

 

How can I fix it?

 

Thanks.

  • Which device are you using? Which version of the SSP? and Which toolchain?
  • In reply to Jeremy:

    Sorry for the lack of information.

    I am using S7G2SK and e2studio with SSP1.3.3

     

    Under normal circumstances it will return 0 normally on failure, this situation does not appear.

    Using mbedtls, It occurs during tls socket connection.

    Below is the log taken directly from the memory allocation (16 * 4byte size) part of mbedtls, and mbedtls calls calloc directly.

    (When the return address of 0x96xxxxxx is returned, I allocate a few times aa variable in a small size of -4 bytes for testing)

    If we want to assign 0x96xxxxxx to the address on the source, we can not allocate it.
    SDRAM does not even exist, but it definitely returns the area (even if you delete the sdram area in the ld file).

     

    2018-07-27 13:11:39.848] [CLP_ERR] hjw 1 alloc ok mbedtls_mpi_grow in=6, nblimbs=16 ciL=4 p=0x20024388 &p=0x20022b0c (mbedtls_mpi_grow:150)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1 alloc ok mbedtls_mpi_grow in=7, nblimbs=16 ciL=4 p=0x96e77308 &p=0x20022b0c (mbedtls_mpi_grow:150)

     

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=1 alloc get bad ptr ok no free aa=0x20024378 &aa=0x1ffe99c4 aa[1]=0xfffffffc aa[10]=0xa1e8f75b  aa[100]=0x1 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=2 alloc get bad ptr ok no free aa=0x20024370 &aa=0x1ffe99c4 aa[1]=0xc aa[10]=0x2f26d3fc  aa[100]=0x200244a0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=3 alloc get bad ptr ok no free aa=0x20024360 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x4387db22  aa[100]=0x8 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=4 alloc get bad ptr ok no free aa=0x20024440 &aa=0x1ffe99c4 aa[1]=0x48 aa[10]=0x0  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=5 alloc get bad ptr ok no free aa=0x20024430 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x3c1bca37  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1-1 aaa size only 4 i=6 alloc get bad ptr ok no free aa=0x20024420 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0xa6b766ef  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.859] [CLP_ERR] hjw 1-1 aaa size only 4 i=7 alloc get bad ptr ok no free aa=0x20024490 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0xfe1a7f9b  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.859] [CLP_ERR] hjw 1-1 aaa size only 4 i=8 alloc get bad ptr ok no free aa=0x96e77300 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x0  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.859] [CLP_ERR] hjw 1-1 aaa size only 4 i=9 alloc get bad ptr ok no free aa=0x96e772f0 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x0  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.859] [CLP_ERR] hjw 1-1 aaa size only 4 i=10 alloc get bad ptr ok no free aa=0x96e772e8 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x0  aa[100]=0x0 (mbedtls_mpi_grow:168)

    [2018-07-27 13:11:39.859] [CLP_ERR] hjw 1-1 aaa size only 4 i=11 alloc get bad ptr ok no free aa=0x96e772d8 &aa=0x1ffe99c4 aa[1]=0x0 aa[10]=0x0

    2018-07-27 13:11:39.848] [CLP_ERR] hjw 1 alloc ok mbedtls_mpi_grow in=6, nblimbs=16 ciL=4 p=0x20024388 &p=0x20022b0c (mbedtls_mpi_grow:150)

    [2018-07-27 13:11:39.854] [CLP_ERR] hjw 1 alloc ok mbedtls_mpi_grow in=7, nblimbs=16 ciL=4 p=0x96e77308 &p=0x20022b0c (mbedtls_mpi_grow:150)

     

    Regards.

     

  • In reply to Jo Sangwoong:

    I have created a simple calloc() test program, and it behaves as expected. In my simple test calloc() returns NULL when when there is no more heap left.
  • In reply to Jeremy:

    Thanks Jeremy

    Already I made simple test program. when there is no more heap left, also it returns NULL.

    In the above situation, it happens returning address of sdram .

    Should I check anything else in this situation?

  • In reply to Jo Sangwoong:

    I am assuming that you are using ThreadX? One thing you could check is that the Thread stack sizes are big enough,  if you open the file synergy\ssp\src\bsp\mcu\s7g2\bsp_group_irq.c and set a break point as shown:-

     

     

    then run the project. If the code stops at the breakpoint, it would suggest a stack is not big enough.

  • In reply to Jeremy:

    Hi Jeremy

    Debugging has been performed by specifying a breakpoint "R_ICU-> NMICLR_b.SPECLR = 1U;"
    , but the event did not occur, and also tested the stack size change, but it did not improve.

    In addition to the problem of returning a 0x9XXX XXXX address when allocating memory,
    there is also a problem in frequently allocating memory.
  • In reply to Jo Sangwoong:

    Hello all

    It is not yet solved,
    Please tell me if malloc function returns a strange address instead of a Heap area.

    Thanks.
  • In reply to Jo Sangwoong:

    I can hardly believe that malloc returns an invalid address. I would rather assume that your application places the heap at an invalid address range.
  • In reply to FrankL:

    using the default newlib malloc in a multi threaded environment is not safe. Please see :-

    sourceware.org/.../libc.html

    and

    sourceware.org/.../libc.html

    however it looks like newlib nano (the default for a Synergy project) doesn't actually make calls to __malloc_lock or __malloc_unlock.
  • In reply to FrankL:

    thanks FrankL

    I can hardly believe that malloc returns an invalid address too.
    In the map file, heap area is correct.(0x20005a90 ~ 0x2007385f)
  • In reply to Jo Sangwoong:

    thanks Jeremy

     

    You mean that in synergy project, when I want to use malloc function I need to lock malloc space?

    I think it is a Linux multi-threaded version library, but is synergy same on RTOS?



  • In reply to Jo Sangwoong:

    Yes, you should lock calls to malloc (if you really need to use malloc). The C runtime library used with the GCC toolchain for Synergy is newlib (sourceware.org/.../) that is targeted for embedded systems, this has nothing to do with the C runtime library that is used with Linux (usually glibc www.gnu.org/.../)
  • In reply to Jeremy:

    Thanks Jeremy

    I'm sorry to bother you,

    I can't search __malloc_lock and __malloc_unlock in the malloc.h(GNU Tools ARM Embedded\4.9 2015q3\arm-none-eabi\include)

    Could you show malloc, __malloc_lock and __malloc_unlock using syntax as an example in Synergy?

  • In reply to Jo Sangwoong:

    Here is a quick example that uses a mutex to lock access to malloc, this will work if malloc (and other functions in the C runtime library that call malloc) are called from a thread context.

     

    S7G2_SK_MALLOC_LOCK.zip

  • In reply to Jeremy:

    Thank you Jeremy

    I will test sample code.