24 replies to this topic

[samjones]

I added the code discussed here:
http://forums.netdui...on-of-this-lib/

And now I am suffering from outofmemory conditions.

Using a netduino + with built in ethernet.

What to do?

Thanks!

>>>>

Microsoft.SPOT.IO.dll
A first chance exception of type 'System.OutOfMemoryException' occurred in System.IO.dll
#### Exception System.NullReferenceException - CLR_E_NULL_REFERENCE (1) ####
#### Message:
#### SDLogging.SDLogger::Close [IP: 0009] ####
#### SDLogging.SDLogger::LogInfo [IP: 0087] ####
#### NetduinoPlusApplication1.Program::ProcessRequest [IP: 005c] ####
#### NetduinoPlusApplication1.Program::GetBusStatus [IP: 0005] ####
#### NetduinoPlusApplication1.Program::Main [IP: 0190] ####
<<<<<<<


My using section:

using Microsoft.SPOT.Hardware;
using Microsoft.SPOT;
using Microsoft.SPOT.Net.NetworkInformation;
using Microsoft.SPOT.Net;

using SecretLabs.NETMF;
using SecretLabs.NETMF.Hardware.NetduinoPlus;

//--------
using System;
using System.IO;
using System.Text;
using System.Threading;

// for the BlinkM tricolor LED
using DominoHost;

// for the sparkfun led matrix
using GHIElectronics.LEDMatrix;

using SDLogging;

[Mario Vernari]

Hello Samjones.
There could be two main causes for going out of memory:

• you are actually requesting too many objects, so that the available memory is not enough to fit them;
• the objects currently allocated fit in the available memory, but there's an high turnaround of life-death objects, and the GC can't perform a good relocation.

Both the contexts are pretty difficult to solve, unless the code is the yours. If so, you may try to save the useful resources, and use them only when they are actually needed.
Also, to limit the GC job, you may try to use static/long-living objects.

Hope it helps.
Cheers

[samjones]

Mario, Thank you! There isn't a lot going on. The problem seems related to the SD Logging code. Perhaps I have too large a block to pass to disk. I will try to limit it...

[samjones]

Is there a way to log (or print debug) avail memory, so I can monitor memory during execution (at least during debugging) ?

[ColinR]

Debug.GC(true); will return the available RAM.

[samjones]

@ColinR: Thanks, will try that out!

[hanzibal]

Well the plus has less than 30k with networking enabled so it's very easy to run out. Got a plus and ran out mem all the time, found it to be not very appropriate for anything demanding a little mem such as SD buffers etc.

[Chris Walker]

Just FYI... .NET MF 4.2 RC4 has a bit of extra RAM. Chris

[ColinR]

RAM limitations on the Netduino can be worked with. My application is fairly complex. Code cleverly and thriftily, and you can come out. The biggest challenge was coming from desktop development where RAM is a non-issue.

[samjones]

Well the plus has less than 30k with networking enabled so it's very easy to run out. Got a plus and ran out mem all the time, found it to be not very appropriate for anything demanding a little mem such as SD buffers etc.

So.... how do I do logging on the plus?

My app itself is pretty simple. But I gotta do networking, and I have to use the high level webrequest approach (I am a hobbyist and lack time to deal with sockets).

[Miha]

Hello guys!

I'm running into the same issue as samjones here. I write settings to SD card. The settings are small, actually just two lines of text. Below is the code I am using to write the settings. The Netduino code is generaly very async (timers, events from cellular shield, etc) and writing is done as a result of a timed callback as well.

Before OutOfMemory, I log Debug.GC(true) and it returns 23448, which I suppose should be enough to write two lines of text. The code that does the writing, below.

Samjones et al, did you manage to solve your OutOfMemory issue?

Kind regards,
Miha.

    #### Exception System.OutOfMemoryException - CLR_E_OUT_OF_MEMORY (4) ####
    #### Message: 
    #### System.IO.StreamWriter::.ctor [IP: 0023] ####
    #### RemoteHeatingRegulation.Program::WriteSettings [IP: 003e] ####
    #### RemoteHeatingRegulation.Program::<DelayedConfigSave>b__7 [IP: 0004] ####

        private void WriteSettings()
        {
            Log.Print("Writing settings");
            if (File.Exists(ConfigurationFile))
            {
                File.Delete(ConfigurationFile);
            }
            
            Log.Print("Memory Available: " + Debug.GC(true).ToString());
            using (var fs = File.Create(ConfigurationFile))
            {
                using (TextWriter tw = new StreamWriter(fs))
                {
                    // write temp settings
                    tw.WriteLine("temp=" + _currentTemperatureSetting.ToString("F2"));
                    tw.WriteLine("furnace=" + (_furnaceSignal.Read() ? "1" : "0"));
                    // write furnace on/off settings
                }
                fs.Close();
            }
        }

[hanzibal]

The stuff you write gets streamed through so that is highly unlikely to be the problem. The problem I had was the size of the buffer used when creating a stream for reading from the SD card.

[Miha]

The stuff you write gets streamed through so that is highly unlikely to be the problem.
The problem I had was the size of the buffer used when creating a stream for reading from the SD card.

So how would you explain the stack trace then? And it happens only on writes. If I don't trigger a write, the ND+ runs without an exception.

Regards,
Miha.

[samjones]

Samjones et al, did you manage to solve your OutOfMemory issue?

Miha,

No, sorry. I gave up on SD writes because it was not critical to my project.

Sorry!

[hanzibal]

That's too bad samjones, are you using the latest firmware? Maybe an upgrade would help.

About the stack trace, it's from the stream constructor which gets created on your first attempt to write and so that would be my explanation. It seems to be this line of code causing the problem:

using (TextWriter tw = new StreamWriter(fs))

I don't know from the top of my head if it's possible but before finally giving up on SD writes, see if you can specify the buffer size using a constructor parameter. Maybe something like this:

using (TextWriter tw = new StreamWriter(fs, 512))

Also check the filestream (fs) constuction to make sure it doesn't allocate too big a buffer.
It looks just as weird as it did for me, I used a 1k buffer and had like 20k available so I never did understand why I ran out creating that stream. Haven't really used my N+ since then which is a huge waste really.

I guess it could be a bug causing the stream writer to attempt allocating way too much memory. Maybe this is a known issue. Either way, this should really be further investigated and you could try and only create the streamwriter alone taking notes on available memory before and after constructor has been executed. It would be interesting learning of your results from doing so.

Please don't give up quite yet

Chris: Do you know anything about this?

Edited by hanzibal, 29 October 2012 - 08:42 AM.

[Miha]

That's too bad samjones, are you using the latest firmware? Maybe an upgrade would help.

About the stack trace, it's from the stream constructor which gets created on your first attempt to write and so that would be my explanation. It's this line of code causing the problem:

Please don't give up quite yet

Chris: Do you know anything about this?

I'll test it a bit further with custom constructors, sure. I'll report back this afternoon.

Regards,
Miha.

[Miha]

I'll test it a bit further with custom constructors, sure. I'll report back this afternoon.

Hi!

I can confirm that changing the File.Create with buffsize 256 works (it was still throwing when I tried 512 bytes). This is strange, since the Debug.GC(true) reports 25k+ free memory.

Solved for now .

Regards,
Miha.

[hanzibal]

Really glad to hear you solved it

I totally agree, there's definitely something fishy going on here.

What firmware version are you running?

[Miha]

What firmware version are you running?

I'm running alpha build with OneWire support.

Miha

[hanzibal]

I was using an older firmware so if it's a bug, this means it survived through a couple of new versions.