Hi!
I use RTX. In my program except the others there are three processes Here they
OS_MUT LOG_MUTEX; #define INIT_LOG_LOCK os_mut_init(LOG_MUTEX) #define LOCK_LOG os_mut_wait(LOG_MUTEX,0xFFFF) #define RELEASE_LOG os_mut_release(LOG_MUTEX) __task void tcp_task (void) { /* Main Thread of the TcpNet. This task should have */ /* the lowest priority because it is always READY. */ INIT_LOG_LOCK; while (1) { LOCK_LOG; main_TcpNet(); RELEASE_LOG; os_tsk_pass(); } } __task void GetHeapsState(void) { char *ptr; unsigned int max=0; while(1) { LOCK_LOG; tsk_lock(); max=1; do{ ptr=(char*)malloc(max); if(ptr) { max+=1; free(ptr); } } while(ptr); printf("%d\r\n",max); tsk_unlock(); RELEASE_LOG; os_dly_wait(10); } } __task void CreatXML(void) { FILE *file_xml = NULL; LOCK_LOG; while(1) { do { file_xml = fopen ("monitor.xml","w"); if(file_xml==NULL) break; fputs("<?xml version=\"1.0\" encoding=\"WINDOWS-1251\"?><form>\r\n",file_xml); .... fputs("</form>",file_xml); fclose(file_xml); } while(0); RELEASE_LOG; os_dly_wait(10); } }
In the beginning GetHeapsState outputs size of the maximum mount memory (number 3909 byte is output). If I will start Explorer and begin to request periodical file monitor.xml after a little later as much as possible selected memory size in the task of GetHeapsState will: 3821 byte. And this number will not change any more does not vary even if we will terminat the request of file monitor.xml. Can you explain me Where disappear 88 byte? I have noticed that the given mistake appears faster if in a parallel way to begin sending any file on fttp.
I am a little stunned. have you considered that the task "GetHeapsState" will never release it scheduler lock, as long as you don't destory's your microcontroller's heap by memory fragmentation? what are you doing here actually? you are a very good candidate to kill somebody in your professional life. I'm saying this with pain and sorrow, but it is, I'm afraid, a fact. Has somebody reviews this code? Are you a PC programmer, originally (or still) ?
"have you considered that the task "GetHeapsState" will never release it scheduler lock, as long as you don't destory's your microcontroller's heap by memory fragmentation?"
What a question! Or is it?
Well, this is probably the weirdest, certainly most dangerous heap test I ever saw! have you noticed the presence of TCPNet, and possibly other components that rely on the heap...?
"Well, this is probably the weirdest..."
Not saying otherwise.
If you were to take a little more time with your responses, they might have less errors. Hope your code is not of the same standard.
Ok. how to check up a heap state?
Hope your code is not of the same standard.
Actually, it is much much much worse. So now you can reply: "I'm not surprised" etc. etc. Man, you can drive a elephant nuts! But I appreciate your concern, really.
first of all, the question is: what do you want to test actually? your current code may compromise system stability by creating memory fragmentation - little blocks that cannot be (re)used. but run time errors that emanate from lack of heap space available must be handled by testing for null pointers that return from allocation functions, and you probably don't want to do it the way you do above. you may want to try to allocate and release larger blocks, and less frequently. but again - TCPNet and other libraries that need heap must return error codes if they run out of heap space, as should your code, too. normally, allocating heap space occurs in the design phase of a system, when the budget of everything is taken into account - including memory requirements.
Steve, Are you trying to portray yourself as my guardian angel? I'm flattered!
How I can know when and for what TCPNet has occupied a heap part? And when has released it?
without access to TCPNet source thus to its memory manager code/algorithm, you cannot. but Keil support can help you make an estimate at to how much heap is required for your application. normally, around 0x400 bytes should do.
http://www.keil.com/support/man/docs/armlib/armlib_cihfiabf.htm
Heap1: Standard heap implementation
The smallest block that can be allocated is four bytes and there is an additional overhead of four bytes.
Heap2: Alternative heap implementation
The smallest block that can be allocated is 12 bytes and there is an additional overhead of four bytes.
To the OP: Avoid to use malloc(), free(), and Heap.