ESP32 Forum

Hi,

We are creating framework SDK using ESP32 IDF 2.1 for our product development purpose in which we ha EA a ported one cloud based component called it as KAA Project Component.

So, Basically, It is working fine and able to access data using cloud based component successfully without any issue. But, When we started it over stress test at that time we found memory assertion issue when requesting multiple requests within some interval which is random issue.

So, We had tracked it down using back trace and cloud based component and we had found only caution for memory assertion issue is like pointer is going to be changed while freeing it but still is shows as allocated.

So, We have checked heap memory code section and put some debugging statements and found that pointer which is going to free is not allocated before but it's allocation flag is set which is little bit strange for that.

So, Somehow, Pointer is going to be changed which we need to find out. We have also tried with heap trace memory debug enable option as well but didn't find much details for memory leakage or corruption issue.

Does anyone e has any idea or clue to debug that issue?

Hi Espressif Systems Developer,

Any Update regarding this issue?

Let me know if need anything else or need some more information regarding this.

Ritesh wrote:Let me know if need anything else or need some more information regarding this.

I'm thinking your question is too ambiguous.

- What pointer are you referring to in your question?
- What operation is occurring when this happens?
- What code are you executing?
- How much free heap space do you have? 32 bit and 8 bit?

It's very easy to run out of memory for socket based operations. I'm struggling with that all the time and I have 4MB of ext spi ram, which is appears isn't used in the TCP/Wifi stack.

John A

As fly135 says, there's not enough information here to debug the problem you're describing.

We don't know of any memory corruption problems in IDF V2.1 itself. There is a problem after calling realloc() under some low memory circumstances if heap poisoning is turned on (fixed in V3.0), but if you're not enabling heap poisoning then this will not be an issue.

Ritesh wrote: So, We have checked heap memory code section and put some debugging statements and found that pointer which is going to free is not allocated before but it's allocation flag is set which is little bit strange for that.

So, Somehow, Pointer is going to be changed which we need to find out. We have also tried with heap trace memory debug enable option as well but didn't find much details for memory leakage or corruption issue.

I don't understand what "it's allocation flag is set" means, do you mean in the internal heap structure? Are you sure it's a valid heap block and not an old heap block or some other invalid data?

I would recommend persisting with heap tracing for this. If you can enable HEAP_TRACE_ALL mode tracing then you can dump recent heap activity and see any instances where this memory address was returned by malloc() or passed to free() previously.

Any specific details (actual errors, actual debug output) may help. Although to be honest this kind of heap corruption issue is usually complex to debug, and unlikely to be easily solved via forum.