Recently (about the last week) we have started getting the 'rtp57 maximum variables exceeded' message on r/basic AND tcl routines (mostly selects and savelists). Just a few random processes a day.

A certain job/program will run just fine, and then - without being changed or re-compiled, fail with this error. When arev is restarted, then that job/program will run fine again.

The 'rtp57 max var' error seems to occur on different computers, almost like a roving error message.

I'm stumped. Any suggestions on what to look for?

Arev 3.12, NLM 5 and Netware 6 with Win2k and XP workstations.

Look for multiple TCL levels and dimensioned arrays. Each element in a dimensioned array uses up a separate variable. If you make a lot of use of dimensioned arrays, consider recoding to use dynamic arrays instead.

Also, note that labeled commons are persistent. once used, variables in labeled commons continue to use those variables for the duration of the session.

Would the use of these be able to effect the same program, that ran earlier today just fine, not running later in the day?

Two of recent 'rtp57 max var' errors where on TCL SELECT statements.

And that program is not changed or even re-compiled.

I am presently at a client's site and they are experiencing the same issue, also starting within the past week or so. From an Advanced Revelation standpoint, nothing has changed. The only changes that we believe have been made are the automatic Windows Updates, of which there have been an unusually high number of in that timeframe. One of the network "experts" was speculating that Microsoft might be sending updates that are based in part on the new Vista technology, and are therefore less "DOS friendly".

I have experienced this same problem in the past.

Here is my example

A program that loops doing alot of suspend commands.

perform 'SUSPEND EXIT MOVE "doc to dir" '

Solution

These are placed within the loop.

GARBAGECOLLECT

FLUSH

Hope this helps

I am familiar with the combination of GARBAGECOLLECT and FLUSH, but I don't believe that applies to the problem in question. These same programs have been running for years without problem, and this problem just manifested itself within the past 10 days…incidently, I am at the client's site today and none of the workstations have had the problem; yesterday they couldn't go 15 minutes without it occurring. I didn't change anything, nor did the network people (or so they say), but I believe that something (a server, a hub, a router) was restarted and that may have resolved the issue…though who knows for how long.

Thanks for the suggestion…

It could be the NTVDM memory leak rearing its ugly head. Why it should crop up now is anybody's guess. You have to see what has changed either on the workstations or server since it started.

EMS Magic might be a solution.

I would expect that to produce an out of string space message instead of maximum number of variables exceeded.

True, but it could depend on where the memory corruption is happening. EMS Magic is relatively painless to install and well enough behaved that it's still worth giving it a try.

Pressing the # at the debugger prompt will do a garbagecollect and display the descriptors used, string space and program stack size. This could be revealing.

I went to install EMS Magic yesterday, but I noticed that they already had EMS enabled and available. I couldn't try the # at the debuger prompt as it doesn't break to the debugger…it just keeps displaying the error message over and over without stipping.

let's try stopping instead of stipping…lol

Using the # in the debugger isn't an option as the 'rtp57 max var' error makes arev dead and we can only kill the ntvdm session.

I'll try the # during some testing I will be doing soon…maybe we are just too close to eating that last cookie….Monty Python style.

Some of our 'rtp57 max var' errors happen like this:

1.  Log onto Arev

2.  Run some TCL Selects.

3.  Get the rpt max var error.

so we have a fresh ntvdm session and a fresh arev session.

FYI - there is a 4K ntvdm memory leak in Win2K (haven't tried XP) each time Arev shells out to dos and returns. Leaving computers up for longish times will make this leak accumulate to very large. We warn users after 3 days of arev session up-time to logout of arev, and force an arev logout after 7 days. This solved that leak. (Most users logout each night as required and the rest freak and logout of arev when the 3 day warning appears).

Sysinternals Task Manager shows my ntvdm session using only two recently changed dll's USER32.dll and GDI32.dll. At least one of the last windows updates seems to have had a patch to the NT kernel…I think. Dates on some of the 'new' dll's seem to be a month or more in the past so I can't tell if the ntvdm/wow sub-system HASN'T been changed recently.

My System.ini file got updated in the last Windows Update it seems too, but I don't know what it used to contain.

I'll will check out the EMS Magic. Thanks for the tip! Need some of this 'magic' to keep dos alive…

That sounds very familiar, I think I've seen it happen when EMS wasn't working.

ARev 2.x used to do bizarre things when the base memory got below 200K, like @record, @ID etc. getting stepped on, commons filling with garbage - stuff like that. v3.12 is a bit better behaved.

Not very helpful, but scary, is that in the April 10th windows update we applied, was the hot patch KB931784 which updates and "fixes" how the ntvdm and the windows kernal communicate.

I have tried the auto-uninstall on this update, but the behavior is the same and consistent on my pc. So I re-applied this patch since the boss is quite insistent on getting all the patches. Either this patch has nothing to do with the problem or the uninstall didn't.

One interesting point is that prior to every single arev crash due to the memory issues, arev goes to zero percent cpu utilization for several minutes, then to maximum cpu utilization for several minutes then the crash. Then just today started using Emsmagic, and now I get a quite long arev "freeze" and no crash. After the freeze instead of crash my arev session will resume and appears to run fine…

I have the same problem that recently started happening after a Windows update. I've heard on a weather station forum that this may be related to Windows recognizing the first USB port as the mouse, even if there is no mouse, or something along those lines, unless that is a different problem. I haven't had time to investigate, but the periodic halts get really annoying after a while.

Yes………………………they…………………………….. certainly……………………………do.

BTW, when my system freezes, it does so for a few seconds (not minutes). At first I thought the problem was related to my screen saver (BOINC, which is very CPU intensive), but looking at the performance monitor, it was clear that EVERYTHING halted during these pauses – at least that is what it looks like.

For me it is just one Arev session. I can have two or more Arev sessions running, and only one will freeze and then crash.

During the initial moments after arev does the freeze, my Sysinternals process monitor will also freeze. The monitor then starts back up.

I have uninstalled, or stopped as many services as possible on my pc. Maybe it will be better.

We have traced the problem with the Arev freezing then crashing with a max variables or out of memory error to windows update KB931784 and maybe KB932168.

A pc with Windows 2000, with these two patches does the bad thing.

A pc with Windows 2000, without these two patches does not.

Seems to apply to XP Pro too, but we have few pc's with XP that we can test this on.

I have also been told that 'uninstall' does not remove the patches by our desktop support gurus.

KB931784 in particular fixes a long standing potential exploit between the NTOSKRNL and the NTVDM.

Kind of like a commercial for Arev32 if you ask me…

We fought this problem back in the W95 days and the fix that we used was to search through the programs which were failing and replace any references which used field names with integers to reduce the number of stack calls the program was making. In other words record was replaced with record like record. If I remember correctly the issue is a stack overflow, and every call to the dictionary results in a call to the stack, so if you eliminate those you can reduce the problem and I managed to make it go away for almost all of our batch programs. This assumes, of course, that your programs are using dictionary calls but I would be surprised if that weren't the case.

We still have one large program that will fail unless you restart Arev before running it to clear out the stack. Since that is easy enough to do and the program only gets run occasionally, we put it in the instructions for running the program.

I think you are on a wild goose chase with Windows updates. It may be that they changed the memory allocation/access somehow but really there's not much you can do about it unless you are going to freeze at a service pack, and that brings up other problems. This (RPT) problem was very hard to nail down, I should know as I spent weeks on it when I was new and the pressure was on to find a fix so we could deploy W95 for our batch processing workstations, reducing dictionary calls was the only thing that worked for us.

I spent a lot of time fiddling with memory and memory settings on the box out side of Arev, all to no avail until I started reducing the dictionary calls.

hth;

David Craig.

David - thanks.

Our issue doesn't require us to actually (I think) use up arev variables or the arev memory with our R/basic code.

If we log onto Arev and immediate run several TCL Selects back-to-back on the same table (at least 3, sometimes a few more) we can lock up the arev session with the following symptoms:

1. Arev session client cpu utilitization is zero for 5-10 minutes.

2. Arev session client cpu utilization max'ed for 5-10 minutes.

3. The Arev session then will crash with the 'max number of variables'. If the 'close on exit' is checked on the pif Program tab, the session just disappears. The pif has to be changed to remove this or you won't see the error.

SOMETIMES the selects will actually finish and the Arev session will freeze up upon the next keypress or two, so when I react immediate I have been able to ONCE get the the debugger and hit # - the memory utilitization looks fine. Then the session will freeze and crash.

We have reproduced this same effect on four different Win2K pc's with these two patches. PC's without these two patches can run the 'back-to-back' selects just fine.

We hope to have a pc built soon without the two suspected patches - confirm that it works just fine, then install the two patches one at a time and see if either/which causes the problem to re-occur.

I'll post our patching test results to let everyone know what we find, since this is looking like a patch issue (to us anyway).

Have you resolved this issue, or is this still happening?

We have avoided the issue by not installing the two patches.

We have not tried to patch with these two and see if the error returns.

Since not installing those two patches has removed the problem, it appears our help desk considers the matter closed.

View this thread on the forum...