Author Topic: Error with Windows Simulator  (Read 9553 times)

Offline Tino

  • Newbie
  • *
  • Posts: 12
    • View Profile
Error with Windows Simulator
« on: January 15, 2008, 11:47:40 PM »
I use the ethernet example exactly as in the tutorial.

if ((TCP_data_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, TCP_DEFAULT_TIMEOUT, fnDataListener)) >= 0) {
         fnTCP_Listen(TCP_data_socket, DATA_PORT_NUMBER, 0);
      }


static int fnDataListener(USOCKET Socket, unsigned char ucEvent, unsigned char *ucIp_Data, unsigned short usPortLen) {
   unsigned char ucTestData[10] = {0,1,2,3,4,5,6,7,8,9};
   switch (ucEvent) {
      case TCP_EVENT_CONNECTED:   // Connection has been established
         if (fnSendTCP(TCP_data_socket, ucTestData, 9, TCP_FLAG_PUSH) > 0) {
            return APP_SENT_DATA;
         }
break;
...
return APP_ACCEPT;   //Standard reply which accepts
}

When I call the port with my webbrowser the VS throws an exception
"Run-Time Check Failure #2 - Stack around the variable 'ucTestData' was corrupted.".

When I changed the datatype of ucTestData to unsigned short or int or something, it doesn't crash. But the received data is trash.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: Error with Windows Simulator
« Reply #1 on: January 16, 2008, 12:12:30 AM »
Hi Tino

Are you sure that you took this code from a tutorial. I can't find its reference, but the problem is due to the buffer used to send data. The explanation is also here: http://www.utasker.com/forum/index.php?topic=25.msg94#msg94

The TCP transmission routine expects space in the buffer to add a TCP header and it is overwriting some data since the buffer is not correct. This does however show a powerful feature of the simulator when running with VisualStudio. VS is actually performing checks of the stack and it detects a stack corruption - the program has not in facts crashed but instead you are getting a warning. When you increase the buffer size - as happens when each element gets bigger - you are (luckily) avoiding buffer corruption but the results is still incorrect.

When running such code on the target you will not get the warning - it will either crash or corrupt something, which will either not be important or be the cause of strange effects. Such problems can be quite difficult to solve and costly for a project. Therefore it is best that the simulator finds them before they get to such a serious stage.

The link above explains the correct solution.

Regards

Mark