• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 1721 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RL_TCP CRASHES

Ali Asadzadeh

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?

Parents Reply Children
  • 0 in reply to mike morgen

    Are you sure you haven't a stack overflow or a buffer overflow somewhere in your code?
    Or that you might have some variables shared between interrupt handler and threads or between multiple threads that doesn't have proper use of volatile or are properly protected by some critical section?

    Lots of things tends to go strangely wrong if memory gets updated at the wrong time or data gets overwritten.

  • 0 in reply to ImPer Westermark

    Hi,
    I have checked the os with debugger, and every task only uses about 30% of it's stack, This message is with in the net_config file, that the RL_TCP will crash,

  • 0 in reply to mike morgen

    But the stack isn't the only place where it's possible to get a buffer overflow.

  • 0 in reply to mike morgen

    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.