Problems with k_free()

[Will Lizardo]

Hi,

I can run the following code within main.c successfully, but it produces the error as shown in the attachment upon execution of k_free(mem.ptr)  from with aggregator.c. Any ideas why it is not working?

   char *mem_ptr;

   mem_ptr = k_malloc(200);

   if (mem_ptr != NULL) {

       memset(mem_ptr, 0, 200);

       printk("Memory allocated:");

      }

      else

      {

        printk("Memory not allocated:\n");

      }

    k_free(mem_ptr);

    printk("Memory released:\n");

[Håkon Alseth]

Hi,

 

At my side it prints:

*** Booting Zephyr OS build v2.3.0-rc1-ncs1  ***
Memory allocated:
Memory released:

Have you tried debugging your session to see where it occurs? by adding "CONFIG_RESET_ON_FATAL_ERROR=n" to your project (and to SPM!) you should enable blocking assertion, which might give you a bit more information (look for the "esf" or "esf_copy" variable, which gives information on where the fault occurred)

 

Kind regards,

Håkon

[John]

The code is just for test purposes and runs fine in main.c

When the same code is run inside aggregator.c

It begins to execute k_free(mem_ptr);

When you step inside using debug, it looks almost normal:

Then ends up here and reboots.

SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_hard_fault)
#if defined(CONFIG_ARMV6_M_ARMV8_M_BASELINE)
/* HardFault is used for all fault conditions on ARMv6-M. */
#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE)
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_mpu_fault)
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_bus_fault)
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_usage_fault)
#if defined(CONFIG_ARM_SECURE_FIRMWARE)
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_secure_fault)
#endif /* CONFIG_ARM_SECURE_FIRMWARE */
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_debug_monitor)
#else
#error Unknown ARM architecture
#endif /* CONFIG_ARMV6_M_ARMV8_M_BASELINE */
SECTION_SUBSEC_FUNC(TEXT,__fault,z_arm_exc_spurious)

mrs r0, MSP
mrs r1, PSP
mov r2, lr /* EXC_RETURN */

push {r0, lr}

bl z_arm_fault

pop {r0, pc}

.end

[John]

Or perhaps and easier way is CONFIG_MEM_POOL_HEAP_BACKEND=n in prj.conf

However I'm unsure if this is the right thing to do.

[Håkon Alseth]

Hi,

 

Is that the only change you did?

According to the release notes for zephyr v2.3, this falls back to the "old" allocation:

https://github.com/zephyrproject-rtos/zephyr/pull/25882/files#diff-d5ddd504431bec7f3b9e3d5ab926ec34

 

Are you using dynamic memory allocation very actively (ie: using a lot of mem)? What happens if you set the heap to 24k for instance?

What about your CONFIG_MAIN_STACK_SIZE (or the thread where k_free() is called from)? Since the pointer itself is stacked, it could be an issue there. What is your current main stack size?

 

Kind regards,

Håkon

[John]

CONFIG_MAIN_STACK_SIZE=8192

Yes the following was the was the only change:

CONFIG_MEM_POOL_HEAP_BACKEND=n

When reading the following in kernel.h it almost seems like there is a more "loose" API on top of the heap.

* @note When CONFIG_MEM_POOL_HEAP_BACKEND is enabled, the k_mem_pool
* API is implemented on top of a k_heap, which is a more general
* purpose allocator which does not make the same promises about
* splitting or alignment detailed above.

I don't think we are using a lot of memory, as we are filling a buffer with a few bytes then clearing the buffer when we have issued MQTT statements.

But we are doing this continuously, and in saying that, the problem doesn't develop like a memory leak would, it happens immediately on the first call to K_free

I wish I could offer more insight into the problem.

[Håkon Alseth]

Hi,

 

I am glad to hear that you have a workaround, but it is a bit concerning that this happens in the first place.

I'd be happy to help debug, if you have a simple project that replicates the behavior.

 

John said:

I don't think we are using a lot of memory, as we are filling a buffer with a few bytes then clearing the buffer when we have issued MQTT statements.

Some heap implementations splits into different chunk-sizes, like having x 32 byte chunks, y 128 byte chunks, and so-forth. If you alloc several smaller chunks, it might take up all the blocks that it normally fits into, and start taking up the next chunk size. However; this shouldn't explain the fault on free() call. If the pointer mem_ptr was corrupted somehow, it might cause an unaligned access or out-of-bounds access (both scenarios ends in a fault). I cannot say if that is the case here, as the failure looks very deterministic.

 

Kind regards,

Håkon

[John]

Please advise how I may send you the project by private message. (Commercially sensitive)

I have a suspicion that it's the way that we are forming the project under v1.3 rather than something that is native to zephyr, which is why I'm keen for you to take a look. Because if we have done something stupid it would be great to understand what it was.

Another issue that has become apparent is that we seem to have lost uart_2 connectivity between nrf52840 and the 9160 which worked fine inside v1.2

[Håkon Alseth]

A private case is preferred if you need to share sensitive data. Since you're not the original poster in this case, you will lose access to the case if I made it private; so this scenario falls a bit between two stones.

What you can do in the future is to input a private case, then share it with colleagues (Note: shared users only have read rights, not write)

 

Kind regards,

Håkon