Actually is not the OutOfMemory exception.
In immediate window of visual studio I get the line “Failed allocation for 86 blocks, 1032 bytes”. After that line the FEZ Cerberus stops to reply at web requests.
But there’s no an exception.
What can be?
@ BigFoot - You’ll see that message when something tries to allocate memory and it fails causing the garbage collector to run. Can you print the amount of free memory every so often to see if it slowly goes down?
Yes, I used the Debug.GC(true) command. Is it correct?
This is the output in the immediate window:
[quote]>>>>> Memory: 30564
Memory: 30564
Memory: 30564
Memory: 30564
Memory: 30564
Memory: 30564
<<<<<<<<<<<<<<<<<<<< HERE I STARTED WEB REQUESTS EACH 5 SECS
Memory: 29928
Memory: 28656
Memory: 23904
Memory: 28176
Memory: 26424
Memory: 21852
Memory: 24204
Memory: 24204
Memory: 26424
Memory: 26424
Memory: 24204
Memory: 21996
Failed allocation for 105 blocks, 1260 bytes
Memory: 23520
Memory: 18684
Memory: 20712
Failed allocation for 105 blocks, 1260 bytes
Memory: 23520
Memory: 20676
Memory: 23040
Memory: 21468
<<<<<<<<<<<<<<<<<<<< HERE CERBERUS STOPPED TO RESPONSE AT WEB REQUETS … but why?!
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
Memory: 29244
[/quote]
The row >>>>> Memory is printed each 10 seconds.
Here’s another example, more interesting than the previous:
Finally an OutOfMemory exception is thrown.
But it resumes to reply after a bit, as you can see… strange… and then, another OutOfMemory exception and so on.
@ BigFoot - Even though you have 20KB of memory, it may be fragmented so a contiguous allocation may not be possible. The networking stack does some internal allocations so when you run out of memory, it fails some requests. When some of that memory is later reclaimed, a few requests can complete successfully.
@ John - What do you suggest to do for removing this issue?
@ BigFoot - It’s really application specific. If you find you are running into memory limits on the Cerberus, upgrading to a bigger board may be needed. Before then though, try going without Gadgeteer. It uses a lot of memory. Also make sure you aren’t leaking memory anywhere.
@ John - Going without Gadgeteer? What does it mean?
Maybe avoid using Gadgeteer.WebServer dll?
@ BigFoot - Create a Micro Framework project instead of a Gadgeteer project. I believe in our tests that having Gadgeteer in the project used 40KB of ram itself.
@ John - I followed your first suggestion and I tried to optimize code.
Now, cerberus can bear 1 web request per second without errors and without going below 26k-30k of memory.
In the immediate window I don’t see “Failed allocation …” or OutOfMemory exceptions anymore.
But: during the process of code’s optimization (and then test, obviously) I fell into a strange behavior twice.
After an “heavy load session” of web requests, Cerberus has stopped to respond to web requests not due to an exception … but simply because the web request didn’t reach my code. I put a breakpoint into the WebEventReceived event of the WebEvent object and I found that WebEventReceived wasn’t fired (…and the web browser of my PC was still waiting for a response)!
The strange is that there’s no exception in immediate window or in my code…
Maybe some exception in Gadgeteer.WebServer or similar classes?
@ John - Can’t wait to test the new SDK. Do you know the expected release date?
@ BigFoot - It’s hard to say if it got stuck in the Gadgeteer wrappers. Can you reliably reproduce the issue at all?
@ jango_jas - No firm date yet.