6 replies to this topic

[MaYHeM]

I'm having a problem, where in the Netduino begins first with failed allocations, culminating to out of memory exceptions.
However, I'm checking Debug.GC(true) before each request/response and it reports between 14k-7k.


The Netduino accepts a socket connection and parses the request.
The request contains arguments of duration and recurrence.


psuedo code

int x = 0
loop
{
LED ON
Sleep [duration]
LED OFF
Sleep [duration]

}while x < recurrence

With each toggle of the LED, the Netduino connects to a socket and sends a small string indicating the LED status has changed.

After a short interval of toggling the LED and sending the status, the Netduino begins to run out of memory. It is however reporting that it still has memory to work with.

Any ideas?
1.) Why is it running out of memory
2.) Why does it report runtime memory remains yet throws out of memory exceptions

[Chris Walker]

Hi MaYHeM, There are some objects pinned in memory on the Netduino. The memory between these is available but you may not have a contiguous block big enough (and pinned memory can't be shifted around). Are you using the 4.2 firmware? It gives you more RAM for your application and the garbage collector is now more thorough than before. Chris

[ericcox]

If you post some code and the actual error message you might get better insight into the problem. I would note that some .Net out-of-resource exceptions give the impression of an out-of-memory state, when in fact it's socket/filesystem handles, or some more obscure resource.

[MaYHeM]

Thanks to both of you for your responses.
I am using 4.2 yes.

I will attempt to isolate the behavior and post it in a zip this weekend.
I suspect that you are correct about the socket handle. I am sending a whole lot of rapid streams over a socket.

I'd also note, that once this occurs, I have to clear the Netduino (hold button and boot), then recycle one more time, before I can deploy again and attach the debugger. I sometimes have to do this several times before it will run the Program. It sticks "The debugging target runtime is loading the application assemblies and starting execution.
Ready."

[MaYHeM]

It must have been as Chris described. I was using a Queue collection. Each request would generate a response object which was placed in the queue to be sent over the socket. It would be dequeued and sent. The queue was monitored with a while loop on it's own thread. Apparently the Queue Collection and the short lived queued objects where the culprit. Instead I decided to wrap the send logic in a lock. No more queue, no more object to hold the request, no more out of memory problems. The reported available memory is now doubled. Not only that, but the logic is far more responsive. I'm new to the gadget world. Managing memory this closely has never been a concern. I'm learning to be thrifty. Thanks for your help.

[ColinR]

Managing memory this closely has never been a concern. I'm learning to be thrifty.

It was a fun transition for me too. Going from allocating 8 individual bool values to hold states to a single byte. Stuff you would never dream of in the Pc world.

[Nobby]

I haven't done an investigation yet but I had memory issues when calling three lines of StreamWriter.WriteLine(long) to save three numbers to a config file on an SD card. My netduino would report at least 21kB free mem with GC(true) then the three calls to WriteLine(long) would spew out failures to assign blocks of various sizes in the visual studio debug window before crashing from OOM exception. All I changed in the code was calling long.ToString() on all the numbers before parsing the data to the stream writer. I'm using 4.2.