MKW24x MyWirelessAppEndDevice Memory Leak

[andrewfitzsimon]

Hello,

I am beginning to think that there is a potential memory leak in the MyWirelessAppEndDevice demo for the MKW24x example application and potentially in the 802.15.4 v5.0.3 library.

I have been porting code from the BeeStack build to the KDS build.

I am developing on the twr-kw24D512.

I have MEM_TRACKING and MEM_DEBUG defined.

I have been hitting a panic() call on line 313 of MemManager.c.

I have the app continuously sending beacon requests (scan requests). In the app, instead of setting gState = stateAssociate, I set gState = statScanActiveStart.

This way, each time it finishes a scan, it starts a new one.

After less than 200 scans, the app will crash at MemManager.c::313::panic().

Please help. I can provide anyone with a dump of the memTrack[] structure if needed.

Thanks,

Andrew Fitzsimons

[andrewfitzsimon]

I am now trying to debug this issue using the MEM_WriteReadTest().

I do the following steps when performing a scan request:

1) Check MEM_WriteReadTest() == MEM_SUCCESS_c

2) mlmeMessage_t mlmeMessage = MEM_BufferAlloc(sizeof(mlmeMessage_t))

3) Setup mlmeMessage as a scan request

4) For every beacon indication I'm freeing the BufferRoot and message

5) When I receive the scan confirm I free each pan descriptor block and message

At this point, MEM_WriteReadTest() fails with MEM_ALLOC_ERROR_c.

When I look through the memTrack[] array, every entry is allocated from MEM_WriteReadTest() EXCEPT one who is allocated at PhyPlmeData.c::PhyPlmeTimmedRxRequest()::ln.327

Could someone explain to me who is responsible for freeing the memory that this function allocates, and when it should be safe for me to call MEM_WriteReadTest()?

[georgecapraru · Accepted solution]

Hi Andrew,

The MEM_WriteReadTest() should not be used! It was created to test the memory pools after MEM_Init()!

If you use this function and an error code is returned, then some or all memory buffers will remain allocated!

The PhyPlmeTimmedRxRequest() function is called before an Rx sequence needs to be programmed, and will allocate memory for the packet to be received. Once a packet is received, this buffer is sent to the MAC layer which is responsible for freeing the memory.

If no packet was received at the last Rx sequence, the memory will remain allocated, and the next time the PhyPlmeTimmedRxRequest() function is called, the memory block will be reused.

If there are more than 1 memory buffers allocated by PhyPlmeTimmedRxRequest() after a Scan, then the issue is at the MAC/PHY layers.

Also, it may be possible that the default configuration from MemManagerConfig.h is not enough for your scenario.

You can try to increase the number of blocks in each memory pool and check if the problem persists.

Regards,

George

[andrewfitzsimon]

Hi George,

Thanks for the clarification on the WriteReadTest().

I will experiment with the number of blocks in the pools and get back to you.

--- EDIT ---

I have gone through and doubled the number of each block size in the MemManagerCfg.h

My observations:

1. My system does not hard fault
2. Eventually MSG_Alloc() will continue to return a null pointer
3. 20 out of 20 of the 0x100 byte buffers in memTrack[] are marked as MEM_TRACKING_ALLOC
4. 19 of the 20 0x100 byte blocks were allocated by PhyPlmeTimmedRxRequest()

I see that the new MCR20A MKW2xD connectivity middleware has been posted and is using a MAC/PHY v5.0.4. I will be upgrading my app to use this version and see if the problem is resolved.

I do believe there is a memory issue around PhyPlmeTimmedRxRequest() in the 5.0.3 version. I'm crossing my fingers it was addressed :smileywink: