plugdata-team
premature stack overflow
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 48a87affd
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!
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.