Stack overflow


    Aug 01 2008 | 8:36 am
    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

    • Aug 01 2008 | 9:51 am
      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?
    • Aug 01 2008 | 10:43 am
      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
    • Aug 01 2008 | 10:50 am
    • Aug 01 2008 | 11:10 am
      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.
    • Aug 01 2008 | 1:04 pm
      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
    • Aug 01 2008 | 1:12 pm
      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...
    • Aug 01 2008 | 2:16 pm
      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.
    • Aug 01 2008 | 3:11 pm
      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...)
    • Aug 02 2008 | 1:31 pm
      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
    • Aug 04 2008 | 8:25 am
      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
    • Aug 04 2008 | 11:07 am
      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.