Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 19 MAY 2004 11:16:25AM Jared Lessl wrote:

I have looked up all the previously discussed variations on this problem and none of the solutions seem to apply. We are getting this error on execution of apparently randomly chosen subroutines. There is no attaching or detaching of tables, nor SELECTS or UPDATES of symbolic indexes. Futhermore, we have a number of AREV databases running the same programs and these problems are only showing up on two of them, and then only when run on Win98 (at least, I have yet to see it on 2k or XP).

I tried putting a "T@" trace and inducing the error, and in 3 attempts it broke on 3 different subroutines in wildly different parts of the program. Two of them (called as output conversion from a window) were utterly simplistic and did nothing more than open a table and read a record. So I have no idea which programs should be declared EXPENDABLE, since no particular one seems to be the culprit.


At 19 MAY 2004 11:21AM [email protected] wrote:

Can you examine the program stack when it breaks and see what the culprits are?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 19 MAY 2004 11:28AM Jared Lessl wrote:

Nope. If I try PS or RP then I get another "Program stack is full" error and the debugger crashes too.


At 19 MAY 2004 11:39AM Matt Sorrell wrote:

Are you using lots of {} dictionary calls?

I had this problem once when using @DICT, @RECORD, and @ID, and then making {} dictionary calls for values.

I cleaned those up to either read the record, or perform xlates instead, and the problem cleared up.

Also, have you checked the memory available from WHO?

[email protected]

Greyhound Lines, Inc.


At 19 MAY 2004 11:50AM Jared Lessl wrote:

Nope, no dictionary references like that.

I did a # from the debugger after getting the stack error. IIRC, it gave me something like 240K string space free. I'll try a WHO next time.


At 19 MAY 2004 11:52AM [email protected] wrote:

What's the exact error message number? R27.??

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 19 MAY 2004 12:04PM Jared Lessl wrote:

_———————————-Clm.300————–

¦ ¦Charge

The Program Stack is full. Press a key to continue.ill T

¦ Received : Logged: ¦Bill #

¦ Resubmit : ¦Prex

¦————————————————–¦Subrog

¦ Accident : Precertification: ¦2nd Op

¦ Diagnosis: ¦Negot

At which point I break to the debugger.

Line 1 'RTP27' broke because the BREAK key was pressed.

Press Esc to cancel the program or G to continue.

!#

The Program Stack is full. Press a key to continue.


At 19 MAY 2004 12:59PM [email protected] wrote:

OK you're running a customised version of the debugger by the look of it. What package are you running?

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 19 MAY 2004 01:15PM Jared Lessl wrote:

Err, package? I'm not familiar with the term as applied to AREV. We're running v3.12, if that's what you mean.


At 19 MAY 2004 03:47PM Ralph Johler wrote:

Similar to the dictionary references, using the Calculate, Calculatex or Xlate to resolve symbolics in a program can fill up the program stack too.

If you have a program, especially one that processes many columns per record, using these three (Calculate, Calculatex, Xlate) suspect it as the problem.

I have had this issue with a data exporting routine, where the user could chose how many columns of data/symbolics for a record they wanted to export to ascii. So most times everything worked fine, but sometimes the exporting routine would crash with 'stack full'.


At 19 MAY 2004 05:59PM Matt Sorrell wrote:

Is your application a "home grown" application, or did you originally buy it "off the shelf."

For instance, I support HR-1, developed by Ceridian in ARev 3.02.

Another possibility is that at some point a replacement debugger was dropped into your system.

Basically, the debugger output you provided is somewhat different that the "stock" debugger messages from ARev, hence the questions.

[email protected]

Greyhound Lines, Inc.


At 20 MAY 2004 04:05PM Jared Lessl wrote:

Very much homegrown. And I'm not aware of anyone having switched debuggers. How would I check?


At 21 MAY 2004 03:16AM [email protected] wrote:

Check the date/time/file stamp on $RTP25 and $DEBUGGER and report back.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 21 MAY 2004 10:19AM Jared Lessl wrote:

AREV.BP

DEBUGGER

VAREV*3.1.165

and

AREV.BP

RTP25

VAREV*3.1.165

Unless there's another spot for the date/time stamp I don't know about.


At 21 MAY 2004 10:52AM [email protected] wrote:

Ahhh red herring alert! The screen dump was of an APPLICATION message overwritten by a stack overflow message! OK. Same basic apply regretfully - try putting in a debug before this message occurs and see what's on the stack - something is hanging around!

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 25 MAY 2004 06:32PM Steve Smith wrote:

Has anyone mentioned the old expendable CALCULATEX as a way forward here?


At 26 MAY 2004 11:34AM Jared Lessl wrote:

Except there is no regularity to where the error occurs. Sometimes here, sometimes over there.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/77d20a8ef15eb95c85256e990053e6de.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1