malloc_info() changes the state of the heap

[Chris Johns]

Mentors

• Chris Johns
• Gedare Bloom

Skills

This is primarily a C programming project.

Expected Outcome

The malloc_info function is made to be side-effect free with respect to the C program heap.

Description

The call malloc_info() is useful when looking to heap issues when some allocations are not right. I have found this call changes the state of the heap. I am not sure what is happening but I think a call like this should not effect the state of the heap and only report it.

The documentation for this call, specification of the requirements, and any related documentation around it should be updated when this call becomes side-effect free.

This project could potentially be combined with other projects related to memory allocators.

[z.ling111]

I looked at the malloc_info function and it does not make any calls that i think will change the heap. Will i have to write a test for this?

[Chris Johns]

EPICS base calls malloc_info here ​https://github.com/epics-base/epics-base/blob/7.0/modules/libcom/src/osi/os/RTEMS-posix/osdPoolStatus.c#L34.

Running EPICS on a zynqmp BSP locks up in this call. The pool status call is made when starting various networking services.

[Joel Sherrill]

I agree with Zack. I don't see anything that would impact memory layout via malloc_info(). There is a lock/unlock of the allocator mutex. That goes through a number of thread life routines but none seem to be allocating/deallocating.

[Chris Johns]

On aarch64/xilinx_zynqmp_lp64_zu3eg, arm/xilinx_zynq_a9_qemu and psim the address of the call does not move

[Chris Johns]

I have added a patch that shows the call address does not move. Without this the call address moves. This code prints a message if it has moved ​https://git.rtems.org/rtems/tree/testsuites/libtests/dl09/dl-load.c#n166

Can you could please check and verify this is happening for you?

Thanks

[z.ling111]

Running rtems_main_o1:
Call location different: moved by: 4776 (call:0x205b890 last:0x205a5e8)
dlo1: module: testsuites/libtests/dl09/dl09-o1.c @ 0x205b890
dlo1: dl01_bss1: 4: 0x205b68c: 0
dlo1: dl01_bss2: 4: 0x205b614: %f
dlo1: dl01_bss3: 1: 0x205b608: 00
dlo1: dl01_data1: 4: 0x205b5f4: 1
dlo1: dl01_data2: 4: 0x205b5f0: %f
dlo1: dl01_const1: 4: 0x205b870: 3
dlo1: dl01_const2: 4: 0x205b86c: %f
dlo1: dl01_func1: 1: 0x205b888
dlo1: rtems_main_o2: 0x205c480

It still moves for me but i'm running an erc32 bsp do i need a zynqmp?

[Chris Johns]

Replying to z.ling111:

It still moves for me but i'm running an erc32 bsp do i need a zynqmp?

Is this with the patch I attached?

[z.ling111]

yes

[z.ling111]

ping

[Chris Johns]

Replying to z.ling111:

ping

Sorry, I have been busy on other things.

Did all runs of the test move the call location?

[z.ling111]

only one of them

[Chris Johns]

Replying to z.ling111:

only one of them

That is fine. After a run it should become stable.

[z.ling111]

ok so what to do now about this ticket if we now know that?

[Chris Johns]

This is a regression and needs to be fixed. It is being moved to 7.

Outside of this ticket we need to review the allocator in general and how it has spread outside the score so we can have an exchangable allocator.