RTOS/TM4C1294NCPDT: HTTP server causing heap memory issue.

Hi Mohammed,

You are changing the heap size properly. I'd enable HeapTrack and then you can probably find if you have a memory leak. Take a look at this video/presentation for details on HeapTrack: https://training.ti.com/debugging-common-application-issues-ti-rtos?cu=1127843

The maximum size of the heap is limited by the amount of memory you have. 

Todd

Hi Todd,

Thanks for the reply I used heap track to trace where the memory is getting filled, on continuous HTTP server use the heap is getting filled up and ultimately is out of memory.

On continuous usage of a CGI the previous memory instances must get deallocated right?  But it is not the case here, the heap is getting empty after a certain amount of usage. Let me know if this is the observed behaviour with respect to HTTP server. 

Mohammed,

No. The memory should be freed up. Do you have a sample project that shows the problem? Can you export it and attach it?

Can you attach a snapshot of RO->HeapTrack? I'd like to see the timestamps and sizes of the leaked buffers.

Todd

Mohammed,

Are you still having the problem? If so, can you please do the two things I mentioned in the previous post.

Todd

Hi Todd,

Sorry for the delayed response. I have actually tried both the suggested things and made the following observations. Let me list them down.

1. In order to isolate the issue, I used the sample HTTP server program alone with the HTML file currently in use and observed the heap memory was getting cleared on consecutive calls.

We currently have 4 tasks running in parallel alongside the HTTP server. On removing tasks one by one I found the issue to persist due to a particular task alone. 

2. On checking with the heap track, While running all the tasks. The heap memory available is same until any CGI function call is made and any CGI call made later is not clearing out of the heap. ( Meaning - on idle case the heap memory is not getting filled up ).

While trying to change task priority I made another observation, When the task which is causing this problem is running at any priority higher than 1 and the NDK priority is set to low. The IP assignment doesn't occur.

So the current understanding which I have is one of my task is not letting the heap memory to get cleared. Could you give me any instance when this could happen?

Mohammed,

Let's focus on the memory leak. I'm not sure what you mean by "cleared". Let's use the term "restored" and "leaked". So when back to an idle state, the heap memory is restored means it is at the expected level (good) or there is a leak (bad...since eventually you're going to run out memory).

It sounds like you think the leak is happening in the CGI function. What are you doing in it? Are you creating something and not freeing it. For example, are you creating a socket and not freeing it.

What is the size of the leak?

What version of of TI-RTOS are you using? I remember that we had a leak awhile ago but need to get back in the office tomorrow to figure out the exact details.

Todd

Todd,

Thanks a lot for your reply and correction on the usage of terms. By the term when I used "cleared" I exactly meant your term "restored". 

The leak doesn't seem to be happening with the CGI function even the basic getTIme CGI function from the HTTP TI-RTOS example was also not getting restored.

I have made some progress on debugging this, As mentioned earlier about one of the tasks which when ran alongside the HTTP server the heap memory was not getting restored. In that task I found a quick loop in case of a idle run and there was no sleep put at that place. On introducing Task_sleep at that point helped in the memory getting restored in the heap.

Could you confirm whether this behavior is observed in case of a while(1) without a sleep running along with the HTTP server. Is introducing sleep the way to resolve this? 

Hi Mohammed,

Mohammed Zakariya said:

The leak doesn't seem to be happening with the CGI function even the basic getTIme CGI function from the HTTP TI-RTOS example was also not getting restored.

Is there an extra "not" in here. Was there a leak in the getTime CGI function?

What version of the NDK are you using?

Mohammed Zakariya said:

I have made some progress on debugging this, As mentioned earlier about one of the tasks which when ran alongside the HTTP server the heap memory was not getting restored. In that task I found a quick loop in case of a idle run and there was no sleep put at that place. On introducing Task_sleep at that point helped in the memory getting restored in the heap.

This does not really make sense. You should simplify the application and see if there is a leak. For example, just have the HTTP server running. Is there a leak?

Todd

Todd,

The NDK version I am using is ndk_2_25_00_09.

Maybe I was not clear in putting out my observations. This is the order in which I made my observations.

1. Basic HTTP example - No leak, memory is restored.

2. My CGI implementation (ran independent) - No leak, memory is restored.

3. Basic HTTP example with other tasks from my application - Memory is not restored

4. My CGI implementation with other tasks from my application - Memory is not restored

5. My CGI implementation after adding sleep in those tasks - memory is restored.

Mohammed,

Got it! Thanks for spelling it out for me. 

It does seem strange and nothing jumps out to me. Can you export and attach #3 to this thread. It'd like to try and reproduce the problem here. I'd like to also understand what the other tasks are doing (e.g. looping forever, what their priority is, etc.).

Todd

Mohammed,

Any update?

Todd

Hi Todd,

Sorry Todd, the adding sleep thing helped me move forward hence I didn't debug much into the issue. I will attach my working sample project replicating one with the similar scenario. Can you please look into this issue which I am currently facing on priority.

Your comments on this would be really helpful.

https://e2e.ti.com/support/microcontrollers/other/f/908/t/824652

i'll take a look at the other one and see if I have anything to add. 

Todd