M52233Demo apparent HTTP server leak

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

M52233Demo apparent HTTP server leak

Jump to solution
1,292 Views
samiran_cj
Contributor I

Using the EMG http Server/ Interniche stack on a M52233Demo board using Coldfire 7.0 build 15.

 

Using the command line heap memory statistics I find that it reports exactly 12 bytes regularly disappear off the heap for each HTTP connection and are never returned when the HTML browser / or HTTP connection is closed. Eventually the web server hangs and or the OS crashes if enough repeated connections are made due to memory fragmentation.

 

Is there anyway to prevent this 12 byte leak? 

Labels (1)
0 Kudos
1 Solution
576 Views
bkatt
Contributor IV

You might really be losing 12 bytes after each connection, which would be a bug in the emg server. When we investigated this software, we found that the memory statistics were not accurate. So even when the malloc and free equivalents were used properly, the numbers reported were wrong (they would accumulate errors over time). This problem was fixable, but we did not contribute our fixes back to freescale before adding proprietary enhancements to the memory allocator for our use. We also found the emg web server to be unusable for our needs and stripped it out of our build.

 

The 5223x devices have only 32K of RAM, and freescale used it all up in their demo applications. We found that we could free up RAM for better use by reducing the stack sizes for tasks, reducing the number of tasks, and using "const" to keep several unchanging data tables in flash instead of RAM.

 

It is too bad freescale did not put a little more effort into making this software usable as a foundation for real systems instead of just toy demos. They seem to have abandoned niche lite for mqx, which may be better but is certain to have similar memory size restrrictions on the 5223x chips.

View solution in original post

0 Kudos
3 Replies
576 Views
samiran_cj
Contributor I

Thanks for your kind attention. I did find both your solutions very illuminating. I have just recently become aware of the 3.2 lite, but have hesitated to use it yet, as I am currently using v3.0. I suppose future posts will have to mention that as well.

 

Its a pity, theres no approved forum for contributing fixes to the ColdfireLite/M5223x.

Marc V, if you could please open one for your release on your site it would be tremendously helpful.

 

For those interested in the solution to this, as of now I did isolate the problem to a memory statistic issue in the implementation of npfree() in the Memio.c/Misclib module. 

 

Apparently the MEMBLOCKSIZE which is the sizeof the memory header struct mem_block (12bytes in mine, due to  various DEBUG defines being switched on) for allocated blocks; gets deducted from the mh_totfree  statistic whenever the heap gets fragmented into memory list chains.

 

  mh_totfree -= MEMBLOCKSIZE;   /* we didn't get a header back */

 

The reverse is obviously not happening when the heap gets de-fragmented into a single memory block when a memory free operation takes place. 

 

 

0 Kudos
576 Views
vier_kuifjes
Senior Contributor I

I don't know about the HTTP server, but I do know from experience that Coldfire Lite is far from a bug free package, not even the latest version 3.2. I use the EMG HTTP client, and there are quite a bit of bugs in that also.

 

And I don't believe Freescale is still interested in managing the Coldfire Lite code. I made them aware of the bugs I found and fixed several months ago using a service request, but never heard anything from them anymore...

 

You can find Coldfire Lite V3.2 with fixes for the bugs I found (+ description) here:

http://www.mvdh.be/cf_lite_patched.html

0 Kudos
577 Views
bkatt
Contributor IV

You might really be losing 12 bytes after each connection, which would be a bug in the emg server. When we investigated this software, we found that the memory statistics were not accurate. So even when the malloc and free equivalents were used properly, the numbers reported were wrong (they would accumulate errors over time). This problem was fixable, but we did not contribute our fixes back to freescale before adding proprietary enhancements to the memory allocator for our use. We also found the emg web server to be unusable for our needs and stripped it out of our build.

 

The 5223x devices have only 32K of RAM, and freescale used it all up in their demo applications. We found that we could free up RAM for better use by reducing the stack sizes for tasks, reducing the number of tasks, and using "const" to keep several unchanging data tables in flash instead of RAM.

 

It is too bad freescale did not put a little more effort into making this software usable as a foundation for real systems instead of just toy demos. They seem to have abandoned niche lite for mqx, which may be better but is certain to have similar memory size restrrictions on the 5223x chips.

0 Kudos