SYSTEM ERROR: -s exceeded

[Crittar]

I have some code something like the following:

FOR EACH table NO-LOCK:

FIND FIRST htable
WHERE htable.hval1 = table.val1
AND htable.hval2 = table.val2 NO-LOCK NO-ERROR.

IF AVAILABLE htable THEN
RUN proc1 IN THIS-PROCEDURE.

(more code).

END. /* End for each table */

PROCEDURE proc1:

ASSIGN
var1 = "field name 1"
var2 = STRING(table.field1)
var3 = STRING(htable.hfield1).

RUN proc2 IN THIS-PROCEDURE.

.
. (more of the same)
.


ASSIGN
var1 = "field name n"
var2 = STRING(table.fieldn)
var3 = STRING(htable.hfieldn).

RUN proc2 IN THIS-PROCEDURE.

END PROCEDURE. /* End procedure proc1 */

PROCEDURE proc2:
IF var1 <> var2 THEN
DO:
ASSIGN
p-line[1] = p-line[1] + " " + var1
p-line[2] = p-line[2] + " " + var2
p-line[3] = p-line[3] + " " + var3.

/* The above is simplified - it has various bits of code to ensure that the values in p-line are correctly aligned for printing. */

ASSIGN
changed = true.
END PROCEDURE. /* End procedure proc2 */

When I run the code, I get the following error:

SYSTEM ERROR: -s exceeded. Raising STOP condition and attempting to write stack trace to file 'procore'. Consider increasing -s startup parameter. (5635)

Can anyone tell me why this is and what I can do to prevent it, please?

I don't understand why the stack is "blowing" as I would expect the reference to proc2 to be removed from the stack when the procedure is complete.

:runtear:

 

[Simon Sweetman]

Chris,

This is nearly always caused by unintended recursion.

Are you sure that one of the "run proc2" commands in proc1 wasn't mistyped as "run proc1".

You could try putting some debug code at the top of each procedure that displays the run stack eg:

def var li_level as int init 2 no-undo.

do while program-name(li_level) <> ?:
    li_level = li_level + 1.
end.

message "Stack depth is" li_level view-as alert-box.

With some debugging you should be able to track this one down.

Simon.

 

[Crittar]

Simon,

Thanks for your reply, I will put in the code you suggest and see if that gives any clues.

I am sure that there are no typos in the procedure names as I actually "generated" the code using another program as there were a lot of fields to put through the same test - it would be a case of all wrong or all right.

 

[Crittar]

Even more confused

Simon,

I re-ran the program with your code included...

I also included a count of the number of records read from "table" in the code above.

When the program blew the stack level was 12, the number of records read was 1677 and it was on the second call to proc2 for that record.

I'm even more confused now - the stack level was twelve for all preceding records - why would it suddenly "blow" at that point?

:dead:

 

[Simon Sweetman]

Chris

This is really starting to sound strange. It's gonna sound like I'm grasping a straws now (but that's cause I probably am).

1. Make sure you have installed the latest progress patch.
2. Try putting an explicit return "" statement at the bottom of each procedure.
3. Try replacing the global variables (var1, var2, etc) with input parameters to procedure proc2.
   

      run proc2(
          input "Field name 1",
          input string(table.field1), 
          input string(htable.hfield1)). 
   
            .
            .
            .
       return "".
   
   end procedure.
   
   procedure proc2.
      def input parameter var1 as char no-undo.
      def input parameter var2 as char no-undo.
      def input parameter var3 as char no-undo.
        .
        .
        .
      return "".
   end procedure.

4. Try placing the procedure proc2 in an external .p file.
   [/list=1]

 

[Crittar]

The straws are vanishing!

Simon,

I've tried the program with parameters and global variables - no difference :blue: .

I am now in the process of recoding it - after testing on a smaller subset of the code it seems to "hold up" better if I use the compare function and only call the second subroutine if there is a difference between the fields.

I must confess this one has me totally baffled, we wrote a test program which went to a much greater stack level with no problems.

We also inserted various "debug" counts into both the subset program and the "real" program - they both fell over after a different number of records from the table we were checking but the real program checks various other tables first - the real program fell over after 60,000+ calls to the proc2 procedure (25,000+ of which were for the table which first caused the problem) the subset program which only deals with that table fell over after a mere 28,000+ calls.

The difficulty with this problem is getting a handle on the cause.

I suspect the re-code is simply hiding the problem but in the real world the aim has to be to get the code working.

 

[Crittar]

I have re-coded the program as detailed above and it seems to be working at the moment. I guess this is one to look at when I have more time - I have kept a copy of the failing code so that I can investigate further in the future.:brick:

 

[bwelzen]

You're running out of stack space. Is it possible that your proc1 runs proc2 and proc2 runs proc1 again. You then get a recursive loop which fills up the stack quite quickly.

 

[Simon Sweetman]

See my posting of 20 Mar and the reply on the same date by Chris.

If this was the case you would also expect that it would crash on the first record not record 1677.

Simon

 

[Crittar]

Epilogue

The re-code of the program worked.

I did the compare outside of proc2 using the compare function and changed the functionality of proc2 to simply build the required print line. The program now works perfectly but I still have no idea why it failed in the first place.