Sorry if I've missed something, but I searched for "stack overflow" errors in the forum and found lots of posts, but none of them seem relevant.

I wanted to create an abstraction that acts like the built-in [toggle] object, except that I could send it a [bang( to output the value without changing the state of the toggle (like the other built-in objects such as [number], [symbol], etc.). I also wanted to change the colour of the toggle, rather than just displaying an 'X', to make it stand out visually. So I came up with this, which is just a wrapper of sorts around the actual [toggle], and the state is save in a [number] box so I can send it a bang message.

It seems to work if I have a small grid of toggles (see "test-tgl2".pd). But in a larger, more complex patch, I started getting "stack overflow" errors. (The patch that's getting the error is a bit too complicated to expect anyone to debug for me, so I haven't attached it.) When I click on "Find Last Error", it takes me to my abstraction ("tgl2.pd"), but I can't see anything in it that would cause a stack overflow. I think the problem may be higher up in the calling hierarchy (my abstraction is 4 or 5 levels down), but I'm not sure. Can anyone see anything wrong with my abstraction? It might not be the best design, but it should work, I think.

Thanks.

tgl2.pd test-tgl2.pd

@dfkettle Fresh eyes revealed the problem, the $0-tgl-s receive and sends form a loop with the toggle, the [change] in my version takes care of that, ultimately mine is just yours with the [spigot] and [t b b b] removed as they serve no purpose and a couple things rearranged. Combine that loop and the redundant wire from [mod 2] to [route 0] (error in my previous post on that) and when you have a good number of the toggles all flipping you can fill up the stack. So each instance of the toggle abstraction puts say 5 redundant messages on the stack, when you have only a few of the toggle abstractions it is not an issue since just an extra 20 messages, but have 100 toggles and now you have 500 of those redundant messages and the stack overflows.

I believe doubled wires come from occasional errors in undo/redo, sometimes a connection message does not get removed, but I am only guessing based on that error has popped up on me after a good number of undos/redos. Quick test shows this was fixed in 52, so should not be your issue unless you are still using 51 or older. If you are using an older version you can see the doubled wire by looking for duplicate #X connect messages.

I didn't find any duplicate "#X connect" lines (and I'm on v0.52.1 anyway).

The only thing I'm sending to $0-tgl-r is the color message, which shouldn't cause anything to be sent to $0-tgl-s, should it?

Anyway, I replaced my version with your version (which is much simpler, thanks!), but I'm still getting stack overflow errors. I think it must be something in the abstraction that contains [tgl2], or evern higher up, that's causing the problem, even though "Find Last Error" always points to some place in [tgl2] (not always the same place, though).

@dfkettle said:

The only thing I'm sending to $0-tgl-r is the color message, which shouldn't cause anything to be sent to $0-tgl-s, should it?

Oh, you're right, guess my eyes were fresher yesterday after all. Control clicking on an error message does not always bring up the cause. In this case the toggle abstraction is overflowing the stack but it is what you are sending it that causes the overflow. You got a loop in there somewhere, just need to find it, {print] and [trace] will help you find it.

Thanks. I've never used [trace] before, I'll read up on it. I guess there's no way to print out a stack trace, like in other languages such as C? Maybe some undocumented startup flag or something?

@oid Well, I found the problem and it really didn't have anything to do with my [tgl2] abstraction. It was higher up in the call hierarchy, in an abstraction that reads data from a text file to load into the toggles. As long as I had a small number of toggles (and therefore a small number of lines in the text file), it worked. But if I had too many (I'm not sure how many is too many), I started to get stack overflow errors.

To fix it, I added an [until] object to the abstraction that loads the data. I'm still not sure why the original version doesn't work, though. They both send bangs to the [textfile] object to read the next line, and stop when the last line is read. A timing issue maybe?

The old version:

The new, improved version:

@dfkettle My guess would be it is that the wire from [textfile] to [bang( was connected before the wire from [textfile] to [pd process-line] so [textfile] gets the next bang before it outputs the previous line to [pd process-line], a [t b a] with the right outlet going to [pd process-line] and the left outlet going back to [textfile]'s left inlet would fix it if that were the case. Generally it is a bad idea to roll your own loop, weirdness often pops up, that is what [until] is for. If you loop use [until] unless you have a good reason not too and if you have more than one wire coming out of an outlet use [trigger] unless you have good reason not too.

@dfkettle

I'm still not sure why the original version doesn't work, though. They both send bangs to the [textfile] object to read the next line, and stop when the last line is read.

Every time Pd passes a message down from a control outlet to the next inlet, the position (along with other execution details) is added to the stack. A stack is standard in basically all programming languages. Pd uses it when it reaches the end of a chain -- an object with no connected outlets. Then it needs to "unwind" -- to backtrack through the execution flow so far to find the most recent object with a connected outlet that hasn't been processed. Eventually all outlets will have been processed, and the stack unwinds all the way back. When the stack is empty, this execution cycle is finished.

Your first version tries to make a loop by feeding a bang back into an earlier inlet. This does not unwind the stack back to that point! Instead, every iteration keeps adding to the stack, and it can't unwind until reaching the end.

The stack has a limited size. This type of recursion-for-looping will eventually exhaust stack space; consequently, there's a hard limit on the number of times you can iterate this way. Probably your first version would work with very short text files, but any significant length (maybe even just a couple hundred lines) will overflow the stack. (The fact that recursion works for short loops perhaps leads users to think they can get away with it... but it doesn't scale up, and it never will.)

In Pd/Max, feeding a value back into a prior object's hot inlet without a delay is usually a mistake (unless it's intentionally a recursive algorithm). This is why [until] is necessary: looping without recursion. ([delay], however, is always the end of its chain -- it doesn't output now but instead schedules a future output. So it will unwind after reaching [delay], making it safe to do what Andrew Sorensen calls "temporal recursion.")

Feeding a value back into a cold inlet is always ok.

hjh

@ddw_music Thanks. I found other posts about stack overflows that suggested adding a [delay], but didn't understand why that would make any difference. I'm familiar with the idea of a stack (I'm a retired programmer), but didn't realize that Pd worked that way, I thought it was a simple loop, not recursive.

@dfkettle Me too! (retired programmer). When Pd evaluates an object graph it does a depth first traversal, and you can think of every patch cord traversal as requiring another stack frame since it may have to back up and evaluate a different depth-first path down the tree. So if a patch has feedback via a cord, that's effectively a loop that could produce an arbitrarily large stack. [delay] stops the depth-first traversal (and schedules a new one for a later time), and [until] eliminates the need for the loop altogether.