NB hangs after replying to the post command

[sblair]

Thanks Paul. I'll give that a try.

Some additional notes. I do run everything in release mode most of the time without using the debugger, and that is when I see this happening.

I did load the AJAX demo and also a couple of the other examples and couldn't get this to happen. So it is something somewhere in my app...just no idea where yet.

[sblair]

Paul,

I've done all that. Here's the problem I hit. When I encounter the issue, I'm getting NO info in Task Scan at all. Meaning when I try and hit scan, it all just goes completely blank because there is no communication coming back.

[sblair]

Okay...I just commented out a big init function that the webpage calls and now banging on refresh and POST doesn't seem to cause the lockup.

So I'll just go through the process of elimination at this point to find what the root cause is. It should be relatively easy to hopefully drill down to find the offending code.

Thanks for the tips.

[pbreed]

If you still have serial comms you can get the task stack info dumped to your serial port by calling

void OSDumpTCBStacks( void ); //Dump task stacks...

void OSDumpTasks( void ); //Dump task info...

[sblair]

Thanks Paul! That is a GREAT tip.

Do you happen to know the answer to this question I posted yesterday too by chance? http://forum.embeddedethernet.com/viewt ... f=4&t=1297

Thanks!
Scott

[sblair]

So I found the exact issue and thought I'd post what the cause was for the next person here that finds themselves looking for clues.

I have a function below that is called from the webpage. It goes through and builds a drop down list with about 100 items.

Code: Select all

void WebIProOutputResolution(int sock, PCSTR url)
{
	//Field Type:  Drop Down
	int index =0;
	BYTE i=0;
	BYTE ListIndex=0;
	char str[5000];
	char stemp[200];

	while(sIProResolutionList[ListIndex].uIndex !=0)
	{

		siprintf(stemp, "<option value=\"%d\" %s>%s</option>",sIProResolutionList[ListIndex].uIndex, uSelected[ListIndex+1], sIProResolutionList[ListIndex].tResolution );
		strcat(str, stemp);
		ListIndex++;
	};

    writestring(sock, str);
}

The root cause of my issue is when str is much over 4000 bytes it causes TCP to hang completely when doing the writestring to sock at the end. It didn't *always* do it, but did it very frequently. As I said everything else would continue to run.

I found if I bumped the size of str up to about 6000 then it would fault and stacktrace. So there appears to be a range where it doesn't crash completely but it does kill the TCP engine.

The solution is what I should have done from the beginning which is put a writestring(sock, stemp); in the while loop so I write out each row of the dropdown list as it is being built. At the time it seemed like it would better just writing it all at once. Clearly that was not the case.

Thanks to all for the help.

Scott

[seulater]

sblair, out of curiosity why would you dump a writestring(sock, str); that is that large.
I think it would be better to shoot them out in packet size chunks. I.E. something on the order of no more than 1400 bytes.

try doing this.

Code: Select all

void WebIProOutputResolution(int sock, PCSTR url)
{
   //Field Type:  Drop Down
   int index =0;
   BYTE i=0;
   BYTE ListIndex=0;
   char str[5000];
   char stemp[200];

   while(sIProResolutionList[ListIndex].uIndex !=0)
   {

      siprintf(stemp, "<option value=\"%d\" %s>%s</option>",sIProResolutionList[ListIndex].uIndex, uSelected[ListIndex+1], sIProResolutionList[ListIndex].tResolution );

     writestring(sock, stemp);     

//      strcat(str, stemp);
      ListIndex++;
   };

//    writestring(sock, str);
}

[sblair]

That's exactly the change I was saying I made. It was a few months back when I coded that function. The data that I build the drop down list comes from another device that I read info from over the serial port. At the time I didn't know it was going to be nearly that large as I didn't have an actual unit to see the data set. I think I was also under the impression that I needed to write it in a single shot, much like once you can only send the RedirectResponse() once.

It's working nice now. It would probably be best if the library call for writestring() was properly bounds checked when writing to sock to prevent sock to prevent that behavior from occuring.

[seulater]

what i used for sending string data to my site was the write function.
have you tried that ?

write( fdnet_webpage, webstring, strlen( webstring ) );

[sblair]

Haven't had a need to try that. Other than the size issue which I corrected writestring has been fine. What's the advantage of using the other write method?