Mbed-os: free() throw a HardFault error

[WillyKaze]

Description

While developing an application using a LPC1768 and mbed-os 5.8.6, my code crashes at free() calls.
Having spent 1.5 week on this bug, I'm wondering what would be the reasons for such crashes.

My code is running 3 threads (including the main thread), each one running the following functionalities:

• CANopen communication in the main thread
• application code in the second
• OSC server listening and sending OSC messages over network

Everything runs fine with those 3 threads but has soon as I try to send any OSC message, the code crashes at the same free() call.

I tried numerous time to adjust stack size of the threads without any luck.

I know this is kind of a generic question but being in the dark here, I'm starting to wonder about memory implementation on the LPC1768.

Here is what i've tested so far:

• A simple mbed program calling malloc/free runs fine
• A free() call in the crashing thread doesn't crash the code
• Pointers in the incriminated function are set to NULL after being freed. So I'm sure the function doesn't try to free an pointer that's already been freed.
• Debug profile behave similarly as the develop profile

What would be the additional steps to further debug this ?

Any help would be greatly appreciated.

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

[cmonr]

@ARMmbed/mbed-os-core @ARMmbed/device-os-custom-engineering-and-support Please take a look.

Not sure why this hasn't been mirrored yet.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-894

[deepikabhavnani]

@WillyKaze - It will be good to share code snippet or sample to help you debug OS issue, till then you can verify the free pointer address to make sure it is same where memory was allocated and not incremented anywhere in code.

You can also use memory trace (https://os.mbed.com/docs/mbed-os/v5.11/tutorials/optimizing.html#runtime-memory-tracing) functionality to debug memory issues

[kjbracey-arm]

Usual reason would be heap corruption.A reasonable bet would be that whoever allocated the heap block just before this one has run off the end of their block. So maybe take a quick look there.

If you know deterministically which free call fails, you should be able to inspect the memory just at the point the free is about to happen. Comparing with the memory just after allocating, I expect you'll find something bad has happened to the heap's maintenance structures - length field or link pointer. (Hopefully the corruption is to that block, not something a bit further away).

If you can see what's been corrupted, the content of the corruption might be a clue, else stick a watchpoint in to catch it happening.

[RonEld]

@WillyKaze
I have a couple of questions regarding your description:

A free() call in the crashing thread doesn't crash the code

The title mentions free crashes the code, so I'm confused about this line.

Pointers in the incriminated function are set to NULL after being freed. So I'm sure the function doesn't try to free an pointer that's already been freed.

Is the free and NULL assignment protected by a mutex? Is it possible that after a pointer is freed, but before it is being assigned to NULL, a context switch happens, and another thread tries to free the same pointer?

[WillyKaze]

Thank you to all of you,

I managed to get this one fixed by freeing up some memory.
Thank you @kjbracey-arm for your advice, I will keep that in mind the next time I encounter this sort of thing.