NB hangs after replying to the post command

[cnth98]

I had a sub-routine called by myDoPost(). It process the user submitted data, then reply with an html table with newly added data. But one out of four chances the NB hangs: the table didn't get display, and the browser is waiting and waiting.. Recall the IP and index.htm gives no response unless power down the NB server. However, the other 3 chances of reply successful though.

Running the debugger the problem doesn't happen again.
Insert iprintf at the end of the myDoPost routine showed the response has been sent and it returned. But the browser didn't get it, and couldn't access the NB without power down.

How can I find out what went wrong ?

any help will be greatly appreciated.

[tod]

I don't have an answer but I just wanted to chime in that I'm seeing this same behavior with the Rel24_rc2 tools release. I can't say it's 1 in 4 times but I'll load a new version of the app and it won't respond to an Ajax request sometimes. I can cancel and reissue and it won't ever work. The serial port indicates that the NB is still alive but the TCP stack may not be. On the Dev board if I hit the Reset button, it returns to normal.

This same behavior seems evident when trying to upload an application. Sometimes the upload will fail. All retries to upload will fail. This is after the latest load was working fine. Hit Reset on the board, retry the upload it works fine. I would estimate this happens maybe 10% of the time.

I've only noticed this since Rel24_rc2.

[cnth98]

Never mind, I found the local buffer overflow problem in my routine.
Thanks for the help,

[tod]

You had a buffer overrun that didn't trap? I just upgraded to the 2_5_2 release did a build and the first thing that happened was it couldn't do the update. The progress bar filled part of the way, then reset and then nada. Could no longer see the device on the network. I hit reset, waited for the boot process to finish. Uploaded again no problem. I don't think the behavior I'm seeing is any type of buffer overrun (but as usual I could be wrong). Once it works I don't have a problem. It only seems to be during new loads or immediately after a new load or restart. Once a reset gets things working it keeps working until the next load.

[tod]

Here's the other thing I see (although it's even less frequent)
I'll do a run configuration. It will appear to work (the progress bar shows up, fills up, pauses then disappears). On the serial port I won't get a reboot message. I'll lose contact with the webserver. Hit interrupt to reboot and connect with the web server and see that the new version did NOT upload. The old image is still intact. Never got the failed message from AutoUpdate. It acted just like it does when it works.

Hit interrupt repeate the process and it all works.

Today I actually got into a mode where I had to repeat the interrupt/reload about 10 times before the upload would work. I even tried powering down/up, but it still took multiple tries after that. Then it starting working again every time. I should mention that nothing in the executable code ever changes. Today's tests were all with my unit testing framework and all the code runs only from AJAX callbacks. That means when the unit boots it should be in a repeatable state. Maybe my 5272 is just showing its age.

I always thought that if AutoUpdate didn't fail then the image was loaded and verified. IP Setup shows that boot to application is checked so I'm not sure what would cause, either the unit to not boot or the image to get verified but not copied over into flash. The original program always seems to be OK. I never have to resort to a serial download just multiple warm boots.

When I get a chance I'll see if I can get this to happend my reloading the factory app multiple times.

[sblair]

Just curious if you ever found the root cause for this. I've been running into issues where after doing the POST command on the page it will hang the webserver and requires hitting a reset to come back out of it. During this time other routines are running, so I can see serial commands are still happening but nothing will work with the webserver and I can't autoupdate.

After adding in the AJAX/JSON framework I found that after about maybe 1 in 4 POST commands on the webpage it will kill the webserver and I'll see the AJAX fail at that point as well until I do a reset.

Any pointers on catching that bugger would be great!

I should also add I'm on the NNDK 2.5.2 tools and haven't had a chance yet to update to the latest.

Thanks.
Scott

[greengene]

i hope y'all get to try this on 2.5.3 and see if it goes away.
we start the transition/evaluation to 2.5.3 next week.
the more eyes on the new release the sooner the better.

[sblair]

Bad news!

I just updated to v2.5.3 and this issue still persists. In a nutshell when I reload the webpage (F5) or doing a POST it is random (about 1 out of 4 times) if the webserver dies or not. What happens is I see all the communication to the webserver die. This includes the AJAX updates as well. I'm using the AJAX JSON framework and in the terminal screen I see all the "J" stop printing at the same time.

My other code is all still running I2C and Serial code is still running fine. AutoUpdate and TaskScan are also dead until I do a reset.

Does anyone have a clue where to start with this? There are no traps or anything else that indicates where the issue is.

Thanks.
Scott

[ecasey]

Hi Scott,

Look for a divide-by-zero in your code. I had a situation where v2.5.3 would just stop and the debugger would give a modal dialog error like "invalid code = 64" with no trap. It turned out to be a re-initialized variable and a divide.

Just a thought.

Ed

[pbreed]

My advice for this sort of thing is

1)In prefdef.h uncomment

#define UCOS_STACKCHECK (1) */


2)Turn on taskscan..
#include <taskmon.h>
EnableTaskMonitor();


3)Rebuild EVERYTHING in release mode.

4)Use Task scan to see where http task hangs and or see if you are corrupting your stacks.