to_the_sun

Dumb question: One would expect stack overflows to happen less often with a 64 bit Max/Live combo than with 32 bit, correct?

stack-overflows-and-64-bit-vs-32-bit

but, just for the record, stack overflow don't "happen"... if you get one, there's something wrong in your patch!

weeeell, in very specific case,s i believe it's possible to have astack overflow without an acutal data infinite loop;.. like with an [uzi 99999999] ? iirc i saw it happen once..

weeeell, in very specific case,s i believe it's possible to have  astack overflow without an acutal data infinite loop;.. like with an [uzi 99999999] ? iirc i saw it happen once..


I have pretty regularly used [uzi] with 7- to 10-digit arguments without stack overflow. It might beachball for a bit, but sooner or later Max came back to user control.

Well maybe I'd just like to get a better idea of what exactly a stack overflow is and how processing occurs in a Max patch. My conception is:

- A stack overflow occurs when Max runs out of space in memory (RAM) to store the function that represents any given "leg" of a patch. Since 64 bit allows for utilization of > 4gb RAM, there must be more space to work within before triggering a stack overflow, right?

- I say "leg" because I know that Max works in a depth-first fashion. I guess instead I should ask the question, how much of a patch's code does Max bite off at once, before it chews? Is that solely determined by the variables in the Advanced Scheduler Settings (scheduler interval, poll throttle, etc.)?

Gimme all the info you got, I wanna know exactly how this all works!

Well maybe I'd just like to get a better idea of what exactly a stack overflow is and how processing occurs in a Max patch. My conception is: 

- A stack overflow occurs when Max runs out of space in memory (RAM) to store the function that represents any given "leg" of a patch. Since 64 bit allows for utilization of > 4gb RAM, there must be more space to work within before triggering a stack overflow, right?
- I say "leg" because I know that Max works in a depth-first fashion. I guess instead I should ask the question, how much of a patch's code does Max bite off at once, before it chews? Is that solely determined by the variables in the Advanced Scheduler Settings (scheduler interval, poll throttle, etc.)?

Gimme all the info you got, I wanna know exactly how this all works!


-no, actually it occurs waaaay before your ram saturate or else... i don't know, it seems a rather apocalyptic scenario, no ? Anyway it occurs when an infinite feedback loop is detected - i thought it might be based on a very large number of iterations on very short time, i might be wrong.

-max calculates from-right-to-left, from-top-to-bottom, so everything is calculated at each scheduler "frame" according to those rules ?

Way before RAM huh? Well if it's not the RAM that's determining what the max is it can handle, what is it? I mean yeah, obviously if you accidentally code something with an actual infinite (no way out) loop, that's a stack overflow. But stack overflows occur more frequently than that. Maybe the loop would have ended after 150 iterations, but Max decides to stop it at only 120. I'm trying to work through cases like that right now (

https://cycling74.com/forums/how-many-loops-before-a-stack-overflow),

 reworking patches to avoid recursion, tricky as that might be. I seem to be plagued with stack overflows after being forced to downgrade...

Way before RAM huh? Well if it's not the RAM that's determining what the max is it can handle, what is it? I mean yeah, obviously if you accidentally code something with an actual infinite (no way out) loop, that's a stack overflow. But stack overflows occur more frequently than that. Maybe the loop would have ended after 150 iterations, but Max decides to stop it at only 120. I'm trying to work through cases like that right now (https://cycling74.com/forums/how-many-loops-before-a-stack-overflow), reworking patches to avoid recursion, tricky as that might be. I seem to be plagued with stack overflows after being forced to downgrade...


My comments on the aforementioned thread (linked in Sun's previous post) may help clarify some of the confusion about stack overflow.

Stack overflows and 64-bit vs 32-bit