__malloc_lock/unlock

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

__malloc_lock/unlock

跳至解决方案
4,124 次查看
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

标签 (1)
1 解答
2,827 次查看
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 项奖励
6 回复数
2,827 次查看
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 项奖励
2,827 次查看
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 项奖励
2,828 次查看
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 项奖励
2,827 次查看
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

2,827 次查看
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 项奖励
2,827 次查看
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 项奖励