We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
Calloc and the '51 one reply only the '51 aint no PC Erik
"Now my problem is..." Of course, you wouldn't have any such problem if you didn't do dynamic memory allocation! What made you think that dynamic memory allocation would be a good thing for your system?
Hi, Well, i am using link list for my program and i allocate memory for each node dynamically. Node will be created depending on external event in foreground as well as for passing signals between states in back ground. So instead of using fix memory allocation, i am suing dynamic memory allocation. I make the memory free once event/signal is processed. Here, i want to know the size of heap allocated for my program and free space available in Heap, so that i can restric my dynamic memory allocation. calloc will retrun NULL if sufficient memory is not there, but how can i know the available free memory in heap ? Thanks
Using linked-lists does not in any way require the use of dynamic allocation! Surely, you must know the amount of space available to these lists at compile time? So why not just create the appopriate-sized, statically-allocated list at compile time? You then just link items into a "free" or a "used" list at runtime as required. "i want to know the size of heap allocated for my program" It's your program - you determine this at compile time! "i want to know ... free space available in Heap" Then you need to provide suitable functions as part of your memory-management implementation. Yes - more overhead!
Hi Neil, Thanks for your input. Fianlly i thought to use statically allocated memory for my list. Well, still i have question: "How can i know whats the heap area allocated for my program ? and What maximum heap size is available for my program ?
If you statically allocate, you don't need a heap! You decide the size at compile time!
Hi, You are right that i dont need the heap if i dont allocate memory dynamically. I just want to know how to assing the size of heap at compiler time ?
"I just want to know how to assing the size of heap at compiler time ?" It's not really done at compile time. Look at where you called init_mempool(). One of its parameters is the size, so the size of the heap is as big as you made it! http://www.keil.com/support/man/docs/c51/c51_init_mempool.htm
Thanks Neil. If i ask the same question in a very generic way, means for any processor if i want to know the maximum heap memory available for my program in advance then whats the way for this ?
"If i ask the same question in a very generic way, means for any processor if i want to know the maximum heap memory available for my program in advance then whats the way for this ?" There isn't one! The 'C' language defines only 4 memory-management functions: calloc, free, malloc, and realloc - any others will be implementation-defined (and probably depend upon system calls to the environment). The best you can do is write yourself a standard "wrapper" that makes the appropriate system call(s) based conditional-compilation. BEWARE! you could get yourself into all sorts of trouble here due to the different alignment, etc, issues of different systems...
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