Clear the heap?

Is there any kind of command that will clear the heap to prevent stack overflow? If not, does anyone have any clever code that would work in a similar way?

Thanks very much!

'free()' the heap space that you 'malloc()' and 'delete' the objects that you 'new'?

Thanks. Do you know of any examples of how to use this?

If you've used malloc(), then the information about free() is always right there with it. The two go together always. IF you haven't used malloc() then you don't need to worry about free(). If you haven't used malloc(), then that's good because malloc() is something for the advanced programmers.

If you've used new, then the information on delete is always right there with it. The two go together always. If you haven't used new, then you don't need to worry about delete. If you haven't used new then that's good because new is something for the advanced programmers.

If you haven't used new or delete and haven't used any libraries written by anyone who used them incorrectly, then you shouldn't have any worry about your heap growing out of control. All that will be there are your statically or globally declared variables. So this isn't a problem that really needs a solution unless you have used malloc() or new and if you have used either you would already know what free() and delete do.

Maybe you should describe the actual issue you're trying to get at. This is a bit of an x-y problem.

All that will be there are your statically or globally declared variables.

Err - not on the heap!

@OP The stack and the heap are not related.

Mark

holmes4: Err - not on the heap!

Where do they go?

holmes4: @OP The stack and the heap are not related.

I think he is worried about the situation where they crash into one another and suddenly become related.

Which is usually more of an issue of the stack growing too big. Usually the stack crashes into the heap, not the other way round.

I think neither stack nor heap: http://www.cplusplus.com/forum/beginner/27102/

gfvalvo: I think neither stack nor heap: http://www.cplusplus.com/forum/beginner/27102/

Oh, I see the distinction you're making. Still, they end up on the end of the memory where the heap is don't they? Or are they down below the stack? Where do they end up physically in memory? That was my reasoning saying that. That normally all the stack has to grow into are the globals and statics. I thought it was the case that you could have the stack creep up and corrupt variables.

Maybe I need to go study that part more. I just now how to keep my memory down in the code.

Delta_G: Still, they end up on the end of the memory where the heap is don't they? Or are they down below the stack? Where do they end up physically in memory?

I really don't know. Just Googling. Seems to be a topic of continuous discussion over at https://stackoverflow.com/

gfvalvo: I really don't know. Just Googling. Seems to be a topic of continuous discussion over at https://stackoverflow.com/

Was that supposed to be a link to a certain thread over there? It just went to SO

All pre-defined data goes in the data segment, which is BELOW the bottom of the heap. ONLY dynamically allocated memory (from new and malloc) goes in the heap.

Regards, Ray L.

RayLivingston: All pre-defined data goes in the data segment, which is BELOW the bottom of the heap. ONLY dynamically allocated memory (from new and malloc) goes in the heap.

Regards, Ray L.

OK, that's how I was thinking of it in my head when I said that. I just didn't now that there was a distinction at the line where they met up. I had the two heaped together, pun very much intended.

So in reality, 99% of the sketches we see around here never touch the Heap unless they are using the String class.

I can’r help feeling that notion of clearing the heap in the simple way that the OP mentions it is fatally flawed. It sounds like pulling the foundations from under the building - like Fred Dibnah used to do to old factory chimneys.

The way to prevent stack overflow is to program within the limits of the hardware.

…R

Thank you for the replies. The problem I'm having is a sketch that uses 1250 or so bytes of memory on a Mega 2560. After 24-48 hours, it seems to hang. I've made every variable and object I can find global in an attempt to eliminate what I suspect to be a stack overflow. The sketch uses a lot of libraries (ethernet, lcd, temp sensors, eeprom, RTC, etc) and I believe these libraries create a lot of local variables each time their functions are called.

I am, at best, an intermediate Arduino programmer with no other programming experince (unless you count CNC programming, which I dont).

My theoretical solution would be to erase any non-global memory each time through the loop so any local variables can be initialized any where and never collide with the stack. (I may be getting the stack and heap confused).

My sketch is below :

https://create.arduino.cc/editor/vulture2600/a9da48d7-019a-4fe9-9b98-67beb38f8141/preview

Local variables (except the static ones) are on the stack

Please post or attach your code here. There seem to be a few people that can't access the create website. And I'm one of them :(

vulture2600: My theoretical solution would be to erase any non-global memory each time through the loop so any local variables can be initialized any where and never collide with the stack. (I may be getting the stack and heap confused).

Probably not a very good theory. As noted, local variables (“non-global” as you called them) are on the stack (except static ones). So, that space is freed up every time the function exits.

Consensus seems to be that global and static variables are stored in the same memory region as the heap, but not on the heap proper. So, nothing you can do about those.

From the nature of your question, I assume that you’re not doing any dynamic memory allocation yourself. So, if any of the libraries you’re using are abusing the heap, by not freeing allocated dynamic memory when they’re done with it, then there’s nothing you can do in your code. You’d have to go into the library code, find the pointers, determine when that memory is no longer needed, and free / delete to get the space back.

On the other hand, if the libraries need to hold on to that memory to do their job, that just means you’re out of memory. Rewrite your code so it doesn’t need those libraries or move to a processor with more memory.

[u]Edit:[/u] The above ignores the problem of inadequate garbage collection that I’m told processors in the Arduino ecosystem suffer from. All the code could be playing by the proper allocation and freeing rules but the memory space could still be getting fragmented.

The other thing besides a memory leak would be some sort of runaway recursion.

Thank you for the replies. My sketch has many tabs so it’s hard to post it other than a link to the web editor. I have attached it as a zip. Sorry to make those who are trying to help take that extra step.

It sounds like I have the heap and stack confused. It sounds to me like theres no way to “defragment” the dynamic memory on the fly.

I dont know what else to do. I’ve invested years in this project and it was working quite well at one point. Ever since I installed it in this house I’ve had this problem and at the time I hadn’t made any changes. Its only since that I’ve made changes trying to track down this problem.

Thanks again for all the help. If anyone would be so kind as to take a look at the attached sketch and give me their feedback I would greatly appreciate it.

thermostat_mega_newest5_newProtoShld.zip (36.1 KB)

Wow that's a lot of code. That might take a little bit to go through.

I can't compile it due to missing libraries. When you compile, what does it report for code size and dynamic memory usage?

One place that would cut down on the amount of memory usage a bunch would be to get all the constant strings out of SRAM with the F macro.

lcd.print("NightTemp:");

becomes:

lcd.print(F("NightTemp:"));

and dynamic memory usage instantly goes down by 11 bytes. Do that to all the constant strings in print statements and you'll save a bunch of bytes.