premature stack overflow

[Omar-Misa]

Hi Tim,
i have a patch which searches [text] object for matches. It is used for up to 128 lines. The match term is a symbol of format "item\ n"; where n=0…127. i've built a for-loop which iterates through production of that symbol and n modulos to stay within range. If [text] doesn't contain match term, then the for-loop isn't initiated. i have established a "next" and "previous" message to increment and decrement n.

If text contains "item\ 4", "item\ 5", and "item\ 6", then "next" and "previous" does return a match until i supply "next" when on "item\ 6", or "previous" on "item\ 4".
Supplying "next" on "item\ 6" should initiate a for-loop which generates search terms "item\ (7…4)", where a match occurs, after being modulo-ed.
Supplying "previous" on "item\ 4" should initiate a for-loop which generates search terms "item\ (3…6)", where a match occurs, after being modulo-ed.

i hope that makes sense. i can build a trimmed patch to demonstrate the issue.

A stack overflow occurs and the for-loop is inhibited. Is there a limit on reiteration count in Plug Data?
The procedure works as expected when running in Pd vanilla 0.55.1

Win10
Plug Data 0.9.2 Nightly Build 48a87af

[timothyschoen]

Hi!

Indeed, the stack overflow protection kicks in sooner in plugdata than pd-vanilla. I really should find a way to increase the stack size of the audio thread (by modifying JUCE), but I couldn't figure that out yet, so I just set the stack limit at 600 instead of 1000.

I wasn't aware this was actually causing problems in practice though, so thanks for reporting. I'll find a better way to fix it!

[Omar-Misa]

Thanks!
A stack limit of 600 should be more than enough for my process. At most, the loop only recirculates 127 times. Not to worry though.