Stack size/memory allocation

1

Hi all,

Working on the PluginEditor of an audio plugin in Visual Studio 2019. I’m getting a warning in the AudioProcessorEditor constructor: “C6262: function uses ‘21948’ bytes of stack, exceeds / analyze:stacksize 16384. Consider moving some data to heap.”

It seems that my options are to:
A) Find some data to allocate to heap
B) Increase the stack size

So my question is, is it more reasonable to find something to allocate to the heap, or to increase the stack size? (Or both?) What is a reasonable stack size for a plugin, anyway? Browsing through the forums, it seems that allocating Processor-side data is ill-advised due to performance concerns. But what about Components in the Editor?

Thanks in advance,

2

I would guess the analyzer has been set to warn about more than 16384 bytes of stack usage, but the default stack is bigger than that. (1 megabyte by default.)

1 Like
3

I think the stack memory begins from the thread entry point.
Since the plugin is called via the dynamic library API, you probably won’t have the full stack memory at your disposal… some is already used from the host engine

About question two: allocations in the editor is not a problem

1 Like
4

Thanks for the responses. I’m going to try allocating Editor Components (Buttons, Sliders, etc.) to the heap using unique_ptrs / make_unique.

I recall @JoshuaHodge mentioning that you could do this in one of his AudioProgrammer youtube tutorials, but was confused at the time as to what the advantage of doing this was, and I suppose maybe this is it?

5

An editor Component is usually not that heavy that it couldn’t live on the stack. Also the editor itself is on the heap, so all members/child components are on the heap as well…
The editor is created in the AudioProcessor::createEditor().

I doubt that your problem stems from normal Components. What are you doing in the editor constructor?
Stack memory are variables that you declare inside function bodies.

6

I guess I have to repeat that warning is from the Visual Studio static code analyzer, it doesn’t actually mean you are going to have a stack overflow at runtime. (Predicting that happening is almost impossible anyway, especially in a plugin since the host will already be using some stack space before the calls into the plugin are even going to happen.)

A function using more than 16384 bytes for local variables seems a bit unusual, though. The warning can be easily triggered by doing something like :

void test_stack()
{
    char buf[32768];
    buf[32767] = 42;
}

But I don’t know how you’d end up using more than 16384 bytes for local variables without declaring arrays like that. (I wonder if the static analyzer counts the class member variables as stack variables for the constructor of the class…? edit : Looks like it doesn’t but I didn’t do a very comprehensive test yet.)

7

Or it is indeed the name patron of stack-overflow:
An infinite recursion that grows the stack by at least a return address plus local memory with each iteration…

8

VS can detect simple cases of infinite recursion as a separate issue.

9

I see, some IDEs are better than others. And sometimes the reported problems are not exactly where the solution is. But good to hear that the error message for infinite recursions in VS can be expected to be reported as such.

I never trust compiler errors any further than I can throw them. And I am really bad at throwing

10

I made a mistake. In short, I was creating objects in the Editor constructor that I had meant to declare in the header file. Still going to leave this topic open because I found the discussion useful. Thanks again for the help.