Stack overflow
I'm working on a large patch where I want to make colls out of a large cellblock using a coll which describes the rows and columns to put in the coll.
It uses a counter to go to the next columnnumber, and also a counter to go to the next row number.
So basically it should do this:
Get first row -> Get first column -> Get second column -> etc. -> Put in coll at index 1 -> Go to next row.
Get second row -> Get first column -> Get second column -> etc. -> Put in coll at index 2 -> Go to next row.
But, if I don't put a delay somewhere in the 'loop', it get's a stack overflow after going performing four rows.
Does this mean without the delay it's an actual loop MAX can't handle?
With a delay of 0.00001ms it works fine, but is pretty slow when I want values from say 1000 rows. Using deferlow instead makes it even slower...
Can anybody please give advice?
Kind regards,
Bas
its difficult to give u an answer without seeing the patch...
but from what you describe, i would start by looking at what happens at the 3/4th row - just before the stack overflow.
have u tried trace?
Hello Justin,
Thanks for your reply.
Between the 3rd and 4th nothing different happens than between the others before.
I can't send the patch (working for a company, can't reveal too much).
What do you mean with trace?
I did use the debugger to monitor what happens.
My guess is that MAX sees it as a loop.
So the question is: How can I use a counter to perform the same thing as often as needed, but that waits with the next count till the current is completed.
Bas
Bas wrote:
> I can't send the patch (working for a company, can't reveal too much).
>
Finding a stack overflow in a patch you can't see is kinda tricky you know.
Isolating this part of the patch and replacing jit.cellblock datas
shouldn't reveal much.
I understand it's hard to help without seeing it.
I tried to make it as abstract as possible, and found some interesting situations.
Please take a look at it. I hope someone can explain why the message box from example 1 causes a stack overflow.
And why the counters can cause a stack overflow after like 300 cycles.
I think this is what going wrong in the patch I'm making as well.
Emmanuel, could you post a small example of a counter with a bunch of triggers?
Kind regards,
Bas
ps. Sent the wrong file...
Found out 'zl reg' instead of a message box works as well. (see example 6)
But with a counter it still doesn't work...
Oops...does not work after all...
Only without zl reg or 'storing in a message box and banging later' it does not give a stack overflow...
Does anyone have an idea how to 'prepare' a value and bang it later without having a stack overflow.
Please don't use the older files, they contain a double line to the counter.
In many cases, the stack overflow is caused by asking Max to complete too many operations too quickly (such as recursive counters).
What is sometimes confusing is if you write a test patch that runs the counter a dozen or so times, and the patch works. But when you substitute real data, you get a stack overflow.
The stack overflow can be avoided using a deferlow object. See the attached patch (but please recognize that the version to the left offers no exit...)
Quote: BasS wrote on Fri, 01 August 2008 10:36
----------------------------------------------------
> So basically it should do this:
>
> Get first row -> Get first column -> Get second column -> etc. -> Put in coll at index 1 -> Go to next row.
> Get second row -> Get first column -> Get second column -> etc. -> Put in coll at index 2 -> Go to next row.
Like this? Or am I not understanding you?
with kind regards,
klaas-jan govaart
Thanks for the example Arne. I can definetely use that. I tried to use deferlow, but not in this way.
Klaas-Jan, thanks as well. It's partially what I meant. This is a nice way to get a cellblock in a coll, which I need as well.
But I sometimes also need to get a specific row range and columns in a coll.
Like:
Row 1: Columns 1, 2, 4, 6
Row 2: Columns 2, 4, 6, 7
etc.
But I think I can make it work now.
Thanks for the help!
Bas
Quote: BasS wrote on Mon, 04 August 2008 10:25
----------------------------------------------------
> t's partially what I meant. This is a nice way to get a cellblock in a coll, which I need as well.
> But I sometimes also need to get a specific row range and columns in a coll.
>
> Like:
> Row 1: Columns 1, 2, 4, 6
> Row 2: Columns 2, 4, 6, 7
> etc.
I see. You can lookup specific values after dumping in coll, or straight from jit.cellblock.
good luck with the project.