Where goes the debug information when VS is not running?

Nicolas3 · April 19, 2011, 5:14pm

Hello !

I have a program that is sending a lot of debug information to the console (and makes the GC run quite frequently too…). I am debugging using USB.

I (think : !) I have a weird behavior:

If I start my domino application unattached to the conputer, running on external power, it seems to be able to run fine for days
If I start the same application from VS2010 and let it run in debug mode (scrolling… scrolling), it seems also to be able to run fine for days
If I run the application from VS2010, then hit the “stop” button to continue developping or do something else, or (not sure) if I run the board from USB power only, VS not running : after a few hours, the application seems to be crashing.

Am I getting an exeption only when the VS debugger is not running ? (I did many many tests to try to capture it) : That’s called Murphy’s Law…

Or maybe, when the board is started with VS2010 does the board “stores” in memory the debug information it’s unable to send, and after “some times” I run out of memory ?

Is there a way to send debug information (exceptions, GC calls, etc) to a file on an SD card or USB stick instead of USB ?

If anyone has any clue, it’s welcome…

Thank you very much in advance !

Gus_Issa · April 19, 2011, 5:23pm

When disconnecting from VS, connect MFDeploy instead, do you see anything?

Nicolas3 · April 19, 2011, 5:47pm

I am getting regular Debug Information, as in VS2010, including GC calls, etc.
However, no “backlog”, which seems good : so it may not be storing information ?

Gus_Issa · April 19, 2011, 5:53pm

Switch to serial debugging and try

Nicolas3 · April 19, 2011, 6:02pm

Thank you Gus ! I will let you know, since I need to get a USB-serial ttl adapter. I ordered one over a month ago, but it is still stuck at canadian customs… with my Panda II. Grrrrr They must think I am ordering some bomb parts again

Nicolas3 · April 20, 2011, 2:22pm

Gus,
Using MFDeploy I am able to connect afterwards my program crashed, and it seems to be because of an “out of memory” problem: The “BINARY_BLOB_HEAD” is taking all my available memory. Where can it come from ? I was unable to find what is doing that. I am not using SD cards nor serial communications in my program. 8)

GC: 3msec 63276 bytes used, 1104 bytes available
Type 0F (STRING ): 816 bytes
Type 11 (CLASS ): 3768 bytes
Type 12 (VALUETYPE ): 756 bytes
Type 13 (SZARRAY ): 1968 bytes
Type 15 (FREEBLOCK ): 1104 bytes
Type 17 (ASSEMBLY ): 14736 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 576 bytes
Type 1D (OBJECT_TO_EVENT ): 264 bytes
Type 1E (BINARY_BLOB_HEAD ): 34068 bytes
Type 1F (THREAD ): 1920 bytes
Type 20 (SUBTHREAD ): 240 bytes
Type 21 (STACK_FRAME ): 1860 bytes
Type 22 (TIMER_HEAD ): 216 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 27 (FINALIZER_HEAD ): 144 bytes
Type 31 (IO_PORT ): 144 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 1572 bytes
Failed allocation for 5 blocks, 60 bytes

Gus_Issa · April 20, 2011, 2:50pm

Interesting Can you try a little program that only prints data out and see if you will run into same problem?

The times I have seen before it was because of serial port data not being read.

Nicolas3 · April 20, 2011, 3:52pm

I made a program that is sending a line of text, calling debug.gc(true) and throwing a (catched) exception every 50ms, so it’s sending a lot of debug information, but does not seem to be enough to show the problem. So this might not be related with debug messages stuck in some queue.

The program that shows the problem is very complex, and it might come from so many places ???
It might be arround aborting the HttpListener class or a thread. Still looking… The fact that it sometimes takes hours before showing is not helping !

Nicolas3 · May 5, 2011, 12:21pm

I can now reproduce the problem as much as I want. With USB debugging.
It may be a problem with MS C# 2010 Express, though.

Here is what I get:

If I start the program from MS C# 2010, and watch the output (debug), I never see the problem. I have regular exceptions, which are catched properly within my code, and everything run smooth.
If I stop debugging, my program keeps working.
Then as soon as I get this particular exception (Wiz5100 socket close), the program crash. Even a thread just doing some stupid Debug.Print() then sleep() in a loop stops looping. However, I can still “ping” the board in MFDEPLOY
If I connect using MSDEPLOY as soon as I stopped debugging with MS C#, I can watch the debugging information, but that does not prevent the board from crashing when I get the exception

But,

If I start/reset the board outside of the MS C# debugger, with or without MFDEPLOY monitoring, my program never crashes.

This is what that make me think : when MS C# is “stopping” debugging, it does not say it properly to the USBizi, and when there is an exception, the board try to send it to the debugger that is not here anymore, and then “hangs”.

Is it a known problem ?
Any clue what I could do to prevent it ?
As anyone met this problem before ?

Thank you in advance !

Gus_Issa · May 5, 2011, 1:57pm

I think this all a coincidence. You are running very close from having out of “continuous memory” and so with any little change you get the exception. Add Debug.GC(true); to in your application to compact your heap

Nicolas3 · May 5, 2011, 2:04pm

I have the same problem on Domino and Panda, on USB or Serial debugging :o

Here is a simple program that shows the problem, and hardly uses any memory…


using System;
using System.Threading;

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHIElectronics.NETMF.FEZ;

namespace DebugCrash
{
    public class Program
    {
        public static void Main()
        {
            bool ledState = false;

            OutputPort led = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.LED, ledState);

            while (true)
            {
                Thread.Sleep(5000);

                ledState = !ledState;
                led.Write(ledState);

                try { int a = 0; int b = 1 / a; }
                catch { Debug.Print("Exception !"); }
            }
        }

    }
}

Start the program from MS VC10. It blinks fine…
Stop Debugger : it stops blinking (crashed)
Reset it (not in debugger mode). You can connect/disconnect with MFDEPLOY, it never crashs

Gus_Issa · May 5, 2011, 3:32pm

How do we know it is crashing? With serial it is easy to disconnect VS and then connect a terminal to see what is coming out.

Also, can you ping the device when it “crash”?

Nicolas3 · May 5, 2011, 3:39pm

I know it crashes because it stops blinking.
And yes, I can still ping with MFDEPLOY then.
I can still see the GC dumps every few minutes with MFDEPLOY : just the program is not running any more.

After I stop debugging with VS (“stop button”) I can still “connect” with MFDEPLOY, then just acting as a terminal, as well with USB or serial.

User_5 · May 5, 2011, 4:54pm

This might be normal. When you stop in VS, it stops the program until further commands…

Nicolas3 · May 5, 2011, 5:10pm

Ok ;
However it’s not stopping the program : as the button says, it’s only stopping debugging.
And the program will continue to run for days… untill there is an exception.

Well at least since when you know it, it becomes easier to debug a program…

Gus_Issa · May 5, 2011, 7:11pm

I know on last version on NETMF this is how it was actually. Programs would stop when you stop VS. At least this is what I remember!

Nicolas3 · May 5, 2011, 7:29pm

Thanks to both of you for having time to explain me