Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Out of Memory - Debug.GC(true) says I'm not?!

  • Please log in to reply
6 replies to this topic

#1 MaYHeM


    New Member

  • Members
  • Pip
  • 8 posts

Posted 22 October 2012 - 10:18 PM

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
Sleep [duration]
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

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 23 October 2012 - 05:22 AM

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

#3 ericcox



  • Members
  • PipPip
  • 19 posts

Posted 23 October 2012 - 07:36 PM

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.

#4 MaYHeM


    New Member

  • Members
  • Pip
  • 8 posts

Posted 23 October 2012 - 10:27 PM

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.

#5 MaYHeM


    New Member

  • Members
  • Pip
  • 8 posts

Posted 24 October 2012 - 12:15 AM

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.

#6 ColinR


    Advanced Member

  • Members
  • PipPipPip
  • 142 posts
  • LocationCape Town, South Africa

Posted 24 October 2012 - 08:30 AM

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.

#7 Nobby


    Advanced Member

  • Members
  • PipPipPip
  • 70 posts

Posted 29 October 2012 - 11:21 AM

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.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.