Hi, we are using 80515 core. Here in the code, memory are allocated dynamically in different files using standard library function "calloc". The code is very large in size..almost 58KB & it contains more than 60 source files. Total 5 people are involved in development. Now my problem is to find out the memory which is allocated but not made free in order to avoid memory leakage. Anybody can help me how to findout the unnecessary allocated memory. Here, i am sure that dynamically allocated memory needs not to be there for the life time in the code. Depending on some conditions, we have to deallocate, but unfortunately if it was not deallocated. Also tell me how to know the size of Heap ? Thanks in advance
Thanks Neil and Dan for providing me useful information.
go get a pill that will cure your PCitis the '51 aint no PC Erik
Modify (or replace) the library implementation with a version that takes extra parameters. On malloc(), pass in an indicator of the call point. (__FILE__ and __LINE___ can be used; the strings will take up a lot of memory. You might have to substitute an enum to save space, at the cost of more typing.) The malloc implementation stores this information in its memory allocation overhead. Wrap your new function in a macro so that it looks like the regular call, if you can use the FILE/LINE method. Now, after you run the program for a while, you can inspect the heap (either with your debugger, or by writing a debug function to help out). Ideally you can run the program to a point where all memory should be free, to avoid confusion. You'll be able to see the source file and line that allocated each block. This generally gives you a good hint as to who failed to deallocate the blocks. There are commercial libraries that do exactly this for larger platforms. A general-purpose heap is unpopular enough on the 8051 that such may be hard to find, so you might have to roll your own.
Hi Eric, I am not getting you.
linked lists, malloc, heap, .... why do you not apply '51 programming practices instead of treating it as a PC. If you took, just a few hours, and familiarized yorself with the architecture of the '51, you woud see that certain "common PC C practices" are almost deadly to the '51. In another thread you will see that writing "'51 friendly" C can reduce program size dramatically and at the same time increase throughput. The "statement C is C on any device, you need not know what the device is capable of doing efficiently" is a blatant lie. The '51 ain't no PC Erik
"In another thread you will see that writing "'51 friendly" C can reduce program size dramatically and at the same time increase throughput" Can you tell whats the "51 friendly" C ?
Can you tell whats the "51 friendly" C ? http://www.keil.com/forum/docs/thread7148.asp this, currently active, thread discuss it and Andy state in the 2nd post "Have you paid attention to the section in the Manual on writing optimum code?" Erik