Dear All I have created 3 tasks,
this is task one it has a osPriorityBelowNormal
for(;;) { main_TcpNet (); }
This is task 2 it has a osPriorityHigh
for(;;) { /* Timer tick every 100 ms */ timer_tick (); osDelay(100); }
this is the task 3 it has osPriorityNormal
U8 Rem_IP[4] = {192,168,0,1};//The PC IP uint8_t *sendbuf; tcp_soc = tcp_get_socket (TCP_TYPE_CLIENT_SERVER | TCP_TYPE_KEEP_ALIVE, 0, 30, tcp_callback); tcp_listen (tcp_soc, 1943); for(;;) { osDelay(1000); switch (tcp_get_state (tcp_soc);) { case TCP_STATE_FREE: case TCP_STATE_CLOSED: case TCP_STATE_LISTEN: tcp_connect (tcp_soc, Rem_IP, 2121, 0); break; case TCP_STATE_CONNECT: if (tcp_check_send (tcp_soc) == __TRUE) { sendbuf = tcp_get_buf(1460); //Fill buffer in here tcp_send (tcp_soc, sendbuf, 1460); } break; } }
But when the application runs for some time it will crash and it would tell that /* Locked Memory management function (alloc/free) re-entered. */ /* RTX multithread protection malfunctioning, not implemented */ /* or interrupt disable is not functioning correctly. */
What's wrong? do you have any idea?
But the stack isn't the only place where it's possible to get a buffer overflow.
So,what do you suggest?
That you start with a careful analysis of all of your own code and look at every single place where a pointer or array index or memcpy/strcpy/... is used.
It's also possible to allocate buffers larger than needed and keep magic markers that you can verify if they get overwritten.
Also - you haven't commented on use of variables shared by multiple threads or between threads and ISR where there might be atomicity issues between reads and writes i.e. you can get a task switch or an interrupt in the middle of a variable write so the other task or the ISR picks up data that is halfway before and halfway after that paused write. Or maybe it's a task that starts reading something before the ISR jumps in, and then after the ISR ends continues to read now modified data that doesn't match up with the initial data read.
If above source code reviews doesn't help, then the next step isn't fun. Debugging of a timing-related issue can be evil unless a test case can be found where the error can be reproduced within a reasonable time interval.