__malloc_lock/unlock

cancel
Showing results for 
Search instead for 
Did you mean: 

__malloc_lock/unlock

Jump to solution
2,839 Views
sergeisharonov
Contributor III

Why KDS::newlib::malloc() does not call __malloc_lock/unlock functions? Was locking support compiled out?

I can see malloc_r in the map file but no reference to locking functions.

Regards

Sergei

Labels (1)
1 Solution
1,542 Views
martynhunt
NXP Employee
NXP Employee

Hi Sergei,

If you remove nanolibc from the linker options and simply link in libc, then you will find that malloc/free calls __malloc_lock/unlock. Hopefully this helps you.

Best regards,

Martyn

remove_nanolibc.PNG.png

add_libc.PNG.png

malloc_lock_LIST.PNG.png

View solution in original post

0 Kudos
6 Replies
1,542 Views
martynhunt
NXP Employee
NXP Employee

Hi Sergei,

Yes, they are #define'd out in newlib-nano. The paragraph on malloc in newlib-nano below is from MBED:

Synchronizing Heap Accesses (malloc/free)

The memory allocation routines implementation in newlib-nano include references to MALLOC_LOCK and MALLOC_UNLOCK macros. In the standard newlib library, these macros would be weak references to __malloc_lock() and __malloc_unlock() routines. A project like gcc4mbed could then provide implementation of these routines to use a mutex to serialize access to the heap. However, in newlib-nano these macros are #define'ed to nothing so this isn't possible.

I hope this helps.

Best regards,

Martyn

0 Kudos
1,542 Views
sergeisharonov
Contributor III

Sorry, looks like replies via Thunderbird make it through to the list but all text is stripped. Here we go again:

On 3/26/2015 11:19 AM, Martyn Hunt wrote:

> However, in newlib-nano these macros are #define'ed to nothing ....

Thought as much. Now, newlib makes malloc/free calls behind your back and we do not have any way to protect these hidden calls.

This makes newlib (as it exists in KDS) not safe to use in any multitasking environment.

The only way I see to make it work is to override newlib's malloc/free with protected equivalents. That seems to work for me.

Sergei

0 Kudos
1,543 Views
martynhunt
NXP Employee
NXP Employee

Hi Sergei,

If you remove nanolibc from the linker options and simply link in libc, then you will find that malloc/free calls __malloc_lock/unlock. Hopefully this helps you.

Best regards,

Martyn

remove_nanolibc.PNG.png

add_libc.PNG.png

malloc_lock_LIST.PNG.png

0 Kudos
1,542 Views
sergeisharonov
Contributor III

Martyn,

Thank you for looking into this. However, I believe full newlib is way too bloated for many embedded systems. For me, the better option was to override library malloc/free with FreeRTOS equivalents.

Regards,

Sergei

1,542 Views
ZhangJennie
NXP TechSupport
NXP TechSupport

hello Sergei,

can you please upload your demo project to showcase your issue? thanks!


Have a great day,
Zhang Jun

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
1,542 Views
sergeisharonov
Contributor III

Sorry, looks like replies via Thunderbird make it through to the list but all text is stripped. Here we go again:

On 3/26/2015 12:46 AM, ZhangJennie wrote:

> can you please upload your demo project to showcase your issue? thanks!

Do not have a demo project but here are 3 easy steps to reproduce:

1. In KDS import hello_world_frdm22k demo project from KSDK_1.1.0/demos/hello_world/kds/frdmk22f

2. Add calls to malloc/free somewhere in main(), e.g.:

.....
{
      void *p;
      p = malloc(10);
      if(p)
             free(p);
  }

....

3. Check map file for presence of locking functions:

    grep malloc_lock hello_world_frdmk22f.map

Or use text editor if grep is not available.

You will see that locking functions are not there.

If I add my own locking functions using RTOS locking mechanics they will

not get called either.

BTW, problem was solved by overriding library malloc/free with RTOS equivalents

instead of trying to protect them.

Regards,

Sergei

0 Kudos