36 replies to this topic

[Josh Hawley]

You can try running it with the debugger attached and setting exceptions to break when they are first thrown. That will frequently show you the deepest exceptions (even if they are handled correctly).

 

Hmm... I'm not actually sure if that will work on a netduino, never tried. I know Visual Studio can do it within external code, but I'm not sure how advanced the debugger is for .netMF. 

 

In VS go to exceptions in the debug menu. turn everything on, and leave it running till it throws.

[wendo]

Right, so I got an exception from System.Net.Sockets with an errorcode of 10060 and an m_HResult (whetever that is) of 4278190080 as this line 

using (var response = (HttpWebResponse)request.GetResponse())

10060 appears to be a timeout 

 

My question is why does a timeout cause an exception, and secondly shouldn't the try block that this is encased in catch this anyway? Or does a try block only catch exceptions from the next line?

[Josh Hawley]

When you are catching exceptions inside other peoples code, It is entirely possible that they handled them already so you may not see them.

 

We now know that there is a timeout. Are you sure that the webserver is responding properly?

[wendo]

No, not at all, both sites are internet based so it's entirely possible they are down or have some other issue...

 

The question is how do I handle that cleanly and without causing an exception? Embedding the statement in another try block doesn't work as I've also just gotten a 10053 error (connection aborted) at the same place.

 

Ideally what I'd like to be able to do is detect the exception and either just ignore it (since I'll send again in 30 seconds anyway) or retry it

[Josh Hawley]

I'm confused as to why a try/catch does not work. Are you only catching specific types of exceptions, or are you catching them all with the base Exception?

[wendo]

As far as I'm aware I'm catching everything. I haven't changed any settings to limit what I'm catching and I assume the default is to catch everything?!

[Josh Hawley]

can you post your catch block?

[wendo]

catch (Exception ex)
{
    Debug.Print(ex.Message);
}

The exceptions that occur appear to kill the timer that calls UploadData as far as I can tell. I've still got the debug.print command I added to show the free memory and once one of the exceptions hits that timer stops firing (it's the first line in the subroutine)

[wendo]

After a lot of random googling, it looks like this behavior is actually "by design"

 

Timers using System.Threading.Timer will terminate upon an exception, no matter what you do with it, see here

 

There appear to be a couple of other options I can try although they use System.Timers.Timer and I'm not sure that's in NETMF and not in a position to look right now

[Josh Hawley]

maybe you should spin up a separate thread when the program starts, and have it block using a manualresetevent. then when your timer fires, it just releases the thread (which runs once and then blocks again until next time)

[wendo]

Can you give me a quick example of that by chance? I've done threads before so thats fine, just the blocking and manualreset that I've never heard of before. Also, thanks heaps for all the help!

[wendo]

I think what I'll do is just kill the 30 second timer and call the UploadData routine directly from my main loop, which has been completely empty until now with a Thread.Sleep(Timeout.Infinite) so I'll throw a while loop there with a Thread.Sleep(30000) and just call UploadData from there.

 

That should hopefully sort out the timer being killed issue and I should be able to catch the damn errors

[wendo]

So now I'm onto trying an AuroResetEvent since the delay in the main code just ended up crashing the main thread.

 

The weirdest thing is that I'm still not actually catching the exceptions in the catch block. I've added some text to the Debug.Print so now it looks like this

 

Debug.Print("SF: " + ex.Message);

 

and I get the occasional "SF:" printed, but no actual error. 

 

Still, we'll see if this is any more reliable...

[Josh Hawley]

Sorry I have been MIA. Wedding/Honeymoon 

 

If you are getting "SF: " and nothing else, then ex.Message is an empty string. Try using ex.StackTrace

[wendo]

Right, with ex.Stacktrace we have some success. I'm seeing 

 

SF: System.Net.HttpWebRequest::GetResponse

TempReceiver.Program::Upload_Thread

 

which is about what I had figured. I've seen some people claim the timeout setting doesn't work at the moment in NetMF so that may be related.

 

Also, congratulations on the wedding!

[Josh Hawley]

Thanks =)

 

Seems like we have hit a wall then. sounds like the sparkfun server is not responding fast enough for the timeout every time. you could just wrap the upload section in a try catch and make it loop until it works or fails 20 times. Kinda ugly, but it seems like all we have left until they fix the timeout setting.

[wendo]

It has been in a try/catch the whole time, but it was still bombing out....

 

However, it's been happily running for something like 5 days now, and while it reports the stacktrace now, it's not locking up. I _think_ I either had a dodge network cable or is was the passive POE injector I was using (maybe a combination of both).

 

I've switched toa new network cable and removed the POE injector and it appears to be stable....

 

You'd think working in IT I would have looked at that earlier . I also think putting it in it's own thread and using autoreset has helped too but at the moment I'm leaning towards the cable. After I hit a week I'll put the injector back in and see what happens.

 

Thanks for all your help on this.