Both:
blob(0)
and
blob()
Cause the imp to “run out of memory”, where as blob(1) is fine.
The squirrel simulator has no problem with this:
sq>print(blob().len()) 0 sq>print(blob(0).len()) 0
Oh, by the way, THANK YOU, for including more verbose errors. I would have never figured out what was going on, if it didn’t say “imp crashed, reason: out of memory”, although I do have to do lots of logging to figure out exactly where this sort of thing is happening.
Ok, maybe related (or maybe not). I have noticed, I have gotten out of memory, when there is an error (maybe the code trying to print the error does the crashing).
I have a simple function that requires two args. In certain situations, if I pass 1 by accident, I get “out of memory”, rather then an exception about not enough args.
I believe this relates back to our malloc which doesn’t allow zero byte allocations… probably. Peter will be able to comment more sensibly 
Got example code for the missing args bug?
The malloc(0) thing will cause an error, which is a bug. However, the error should be “the stream is invalid”, so the fact that you’re experiencing it as an out-of-memory error is indeed a second bug.
Peter
Hugo: You still need an example? I was just creating a blob(0) (well, accidentally blob()) to start the size of as 0 and grow as needed. Dies 100% of the time.
I was asking for an example for the two arg function that “in certain situations” gives an out of memory error… if indeed it isn’t easy to replicate.
I just tried to replicate it and would get a silent fall offline into a reboot loop (which is obviously not good, though fixing the code means it’ll come back on the next loop), but not an out of memory error.
The code was something like:
`function debugLog(string, level)
{
local logLevel = gLogLevel ? gLogLevel : 0;
if (level <= logLevel)
{
if (string.len())
{
server.log(string);
}
}
}
debugLog(“Something”);
`
But of course, I believe it is more complex then that, since that alone doesn’t generate out of memory. I just know that I was in a situation, where I was writing a log to debug the “”.find() issue and I got out of memory for debugLog(“I am here”), and putting debugLog(“I am here”,1) fixed it.
Either way, I don’t have time to do real work on my project, so if I get a chance to get it back into a situation that is doing that, I will let you know mac address and you can take a look at the situation causing it.
There may be something else going wrong.
I am reading some data, and then setting the value of my output (I have several outputs I am setting). I am getting out of memory crashes when I do this, unless I sleep(0.1) in between each setting. Maybe related, maybe not.
It is currently in this state.
The MAC address of the device is 0c2a690002e2
The more I think about your out-of-memory problem, the more it worries me. If you don’t want to post the whole code on the public forums, could you send me a forum message with it?
Peter
Ah, never mind, I’ve reproduced this bug with the out-of-memory message – no need to see your code.
Peter
I have an imp exhibiting the out of memory issue. It was working fine with Release 5 but since the firmware update it has stopped working (I haven’t put in any log messages to try and find the exact line - but I don’t have any blob() or blob(0) calls in this firmware.) The imp’s MAC is 0c2a69000462. If you want another example piece of code with the issue I can send it to you Peter.
Yes please – can’t hurt to look at it, even if it ends up being the same issue. (Which I’ve found and will be fixed in the next release.)
Peter
So, I am still having out of memory problems with the latest release. It is when posting to my outputPort. Seems to be random, which one dies. I have an outputPort subclass which saves the last value (I had great plans for this class, but have given up on this for now)…
`
class historicalOutput extends OutputPort
{
_updates = 0;
_value = null;
function set(input)
{
++_updates;
_value = input;
base.set(input);
imp.sleep(0.05);
}
function value()
{
return _value;
}
function updates()
{
return _updates;
}
}
`
I have some code that looks like:
`
debugLog(“here 0”,1);
updateServer.set([“lights”,lightOn
"pump", (pumpOn ? (pumpOnLow ? 1 : 2) : 0),
“fountain”, fountainOn,
“cleaner”, cleanerOn,
“heater”, ((heatPumpOn || gasHeaterOn) ? (heatPumpOn ? 1 : 2 ): 0)]);
debugLog("here 1",1);
lightState.set(lightOn);
debugLog("here 2",1);
fountainState.set(fountainOn);
debugLog("here 3",1);
cleanerState.set(cleanerOn);
debugLog("here 4",1);
// heatpump = 1, gas = 2, off = 0
pumpState.set(pumpOn ? (pumpOnLow ? 1 :2) : 0);
debugLog("here 5",1);
heaterState.set(heaterOn);
debugLog("here 6",1);
`
And I am getting logs like:
November 19, 2012 1:30:38 PM EST: here 0 November 19, 2012 1:30:38 PM EST: here 1 November 19, 2012 1:30:38 PM EST: here 2 November 19, 2012 1:30:38 PM EST: here 3 November 19, 2012 1:30:38 PM EST: here 4 November 19, 2012 1:30:38 PM EST: here 5 November 19, 2012 1:30:50 PM EST: imp crashed, reason: out of memory November 19, 2012 1:30:50 PM EST: Device booting
But the “here” is random, sometimes it gets to here 3, other times here 4 or just here 1. Any ideas?
Oh, just to be clear, the imp.sleep(0.05) was my attempt to workaround this, as the longer it sleeps, the less likely it is to crash. But that doesn’t seem to be the case anymore. Also, I replaced debugLog (my server.log wrapper) with server.log, it still crashes.
Do you have code that will replicate this that we can look at (you can PM it)? I can see you’re semi-low on memory (though you likely won’t be on the next release which has huge memory usage improvements), but what you’re showing here seems very simple and shouldn’t be causing issues.
I just sent it to you. I will also leave it running for you to debug for awhile, going to move onto another project for today.
Is this still an issue? I’m getting
2016-02-01 07:03:37 UTC+11 [Exit Code] imp restarted, reason: out of memory
occasionally, and need to work out what is causing it. I am storing a blob in the nv table, and periodically setting it’s size back to zero when all the data is uploaded:
nv.data_blob.resize(0);
Is that a bad way to ‘delete’ the data?
The original issue here got fixed ages ago. And yes, resize(0) is a perfectly good way of setting a blob’s size (and memory usage) back to zero. So I’m afraid something else must be going on in your device code.
Peter
Thanks for the info Peter!
I found the culprit causing the memory issue. A uart read error that wasn’t being caught.