SYSTEM ERROR: -s exceeded.

Do you still get the "-s exceeded" error when -s is set to 10,000 or do you get different errors?

I don't think you should have to set -s so high to avoid the error, but most applications do need something higher than the very small default value (I think the default is 40). You need more stack space when running with the 64-bit client than you needed for the same application with the 32-bit client because some internal structures grow in 64-bit due to the larger pointers. I've seen bugs where the 32-bit client was just under the limit and the same program gets the "-s exceeded" error with the 64-bit client.

Hi Matt,

If I increase the stack setting to 10,000, OpenEdge automatically ups the nested block setting count.

Unfortunately when it reaches 20,000 the error becomes bfblst - Too many block levels. (1). I am assuming that this is a hard limit? Either way I don't like that this is happening - it does not feel right.

I am tempted to repeat the whole migration using the 64 bit distribution, but would first pose the question "do you think this would actually help this particular situation?"

Thanks

Nigel

The symptoms you describe suggest some recursive fuction going infinite - those will just eat up resources until they blow up in various ways depending on which system limit you hit first.

So what does the application do during the startup ? Including which data it processes ?

I agree with what you are saying, however this application works perfectly well on 9.1E

The applications is a workflow application, but at start up it is simply authorising the logged in user and displaying a simple menu screen - so there *should* be no reason for recursion...

Well, you could assume that there is no issue because the application works on 9.1E or you could turn on client logging and see if there is anything happening differently in your current version.  What's so horrible about turning it on and verifying?

"This application works perfectly well on 9.1E"

That may be, but the interesting question is how the code is *supposed* to work. Then you can identify which points to compare between the working 9.1E and the failing 11.5 environments.

"a simple menu screen - so there *should* be no reason for recursion... "

From experience, I've seen a large number of applications where:

- The menu structure is a tree structure, meaning: main menu, sub menus (possibly with their own sub-menus), menu items under the sub-menus.

- When menu is built, items are added/removed/enabled/disabled based on user-specific data (permissions etc.)

- To traverse (or build) the menu tree, recursion is used to navigate the branches.

I don't know if that applies here, but Brian's suggestion of flipping on the 4GLtrace logging would prove that quickly enough.

Sorry - I did not ignore the suggestion for logging - in fact I have it switched on but am struggling to get any information that I find helpful.

The first line of the log is:

[15/10/01@13:54:33.098+0100] P-004820 T-005100 2 4GL 4GLTRACE       Run palib.p PERSIST [Main Block - d:\apps\paws\runtime\pammain.r @ 536]

The following line is then repeated 500 times (with only the time and 099+0100 value incrementing each time.

[15/10/01@13:54:33.099+0100] P-004820 T-005100 2 4GL 4GLTRACE       Run palib.p PERSIST [Main Block - palib.p @ 18]

This is then followed by:

[15/10/01@13:54:33.255+0100] P-004820 T-005100 1 4GL -- (Procedure: 'palib.p' Line:1) WARNING: -nb exceeded. Automatically increasing from 500 to 600. (5407)

This pattern repeats until the nb count is exhausted at 20,000

This is the key:

[15/10/01@13:54:33.099+0100] P-004820 T-005100 2 4GL 4GLTRACE       Run palib.p PERSIST [Main Block - palib.p @ 18]

Line 18 in that program seems to cause an Infinitive Loop. You should create a debug-listing of that program and check line 18.

COMPILE palib.p DEBUG-LIST c:\temp\debuglist.txt.

OK, I don't have command line COMPILE setup, but have use AppBuilder, specifying a filename for debug output - not sure if this does the same thing, but this basically  provides a copy of the source file but with line numbers added.

Line 18 is simply a declaration:

1   /*

       2       Procedure       palib.p

       3      

       4       Description             5

       6       Created        

       7  

       8       Notes          

       9                      

      10   */    

      11  

      12   &SCOP runprocextent 10

      13  

      14   &SCOP NoChqRun     0

      15   &SCOP SelStart     2

      16   &SCOP SelComp      3

      17   &SCOP AnnDueStart  4

      18   &SCOP AnnDueComp   5

      19   &SCOP CertExtStart 6

      20   &SCOP CertExtComp  7

      21   &SCOP CertLetStart 8

      22   &SCOP CertLetComp  9

      23   &SCOP PrtChqStart  10

      24   &SCOP PrtChqComp   11

      25   &SCOP ChqNumStart  12

      26   &SCOP ChqNumComp   13

      27   &SCOP ChqIssStart  14

      28   &SCOP ChqIssComp   15

      29   &SCOP CovLetStart  16

I guess one of the things I am struggling with is what @ 18 really refers to?

is it line 18 in the original source file?

is it line 18 relative to a particular function?

is it line 18 in the '.r' file? (not particularly useful)

As per the listing above - line 18 in the original source is benign and highly unlikely to be causing any issue

I am not sure where ABL fits here?  this is a 4GL app circa 1999 authored in Progress 9 and earlier.

I have followed the guidance provided by this Progress Article -

knowledgebase.progress.com/.../000042055

which states:

• In the Appbuilder Application Compiler choose Options->Compiler..., then add a debug file name in the fillin "Debug File".  When the file is compiled in the Application Compiler a debug list with the specified name will be created in the working directory.

The debug file I get is as posted above - literally the source file with line numbers added

The AppBuilder also generates a listing file

Thanks Mike, but having only just installed OpenEdge 11.5 I can't find the COMPILE command anywhere - this is why I am using AppCompiler.

I have tried starting from ProeEnv and looked in \bin, but cannot find the COMPILE executable - would you mind providing a few pointers here?

Thanks

You don't have Access to the procedure Editor? COMPILE is executed from the Procedure Editor.

Well, there's an interesting thing...

I have enabled debugging (proDebugEnable...) and started the main program in the Procedure Editor and the application works with none of the stack / nested block issues exhibited in non-debug mode.

This suggests that the issue is environmental, however because it works in the debugger there is nothing to debug.

Any thoughts?

OK, I have this working now.

The problem was very well masked and logically still does not make a great deal of sense, i.e. the symptoms vs the cause.

The culprit was the .ini file that was provided on the command line, which contained the PATH specifications.

This worked perfectly fine in version 9.1E (and indeed was required), but is obviously processed differently at version 11.5.

The solution was to remove the ini file altogether (I made need to add this back in for finer grained font control, but without the PATH/DLC/PROMSGS/PROCFG spec).

Thanks for all your help