#455 memory leak

[Gerard Schildberger]

In the attached REXX program, it exhausts virtual memory (on Windows/XP and Windows/7 with no error message other than Windows informing me that the REXX launcher stopped working).

Why is the REXX program consuming more and more virtual memory as the program executes?

There are no stemmed arrays, no recursive subroutines, numeric digits hasn't been exceeded ...

________ Gerard Schildberger

[Gerard Schildberger]

This was tested with Regina 3.3 ---> 3.9.1)

[Gerard Schildberger]

The REXX program fails during the calculation for the eighth sailor.

[Paul Kislanko]

The program is not doing what you think it is.

sailors=2 coconuts=11
sailors=3 coconuts=25
sailors=4 coconuts=765
sailors=5 coconuts=3121
sailors=6 coconuts=233275
sailors=7 coconuts=823537
11 +++ if nuts//n\==1 then return 0 /Not 1 coconut left? No solut
ion/
4 +++ do $=0 while \valid(n,$)
Error 4 running "D:\Documents\baseball\2015\zzzzz_testboco.rx", line 11: Program
interrupted

Press ENTER key to exit...

Line 11 isn't "not 1 coconut left?" I'm not sure what "remainder when divided by n" actually means in this context, but you've created an infinite loop by expecting that the remainder will not get "stuck" at something that keeps the while clause on line 4 from stopping the loop.

Try implementing your algorithm without using a not symbol.

[Gerard Schildberger]

The thing is to NOT halt the program, but let it finish
(or, most likely, exhaust virtual memory). Use the
Windows task manager to watch its progress and growing
virtual memory). This program does not execute in a
few seconds. Depending on how slow your PeeCee is, you
may have a little wait.

It would be interesting if somebody could execute this
REXX program with the 64-bit version of Regina.
______ Gerard Schildberger

[Gerard Schildberger]

The "remainder when divided by N" means ...
stop the DO K=... loop (and flag this number of
coconuts invalid (or in other words, this number
isn't valid in solving for the number of coconuts.

This algorithm works to find the number of coconuts
for any number of sailors (greater than one).

This algorithm works (as is) for other languages,
and should also work for REXX, ... unless of
course, it consumes all the virtual memory and
causes Regina to crash.

But in any case, large loop or not, why does the
virtual memory keep increasing? Where is the memory
leak?

Using a "not" symbol isn't the problem.

I have NOT created an infinite loop. The number (for
the REXX variable $) is large, nine decimal digits
when solving for eight sailors. It is also nine
decimal digits for nine sailors. At ten sailors,
the number of coconuts goes to ten decimal digits.

Just in case, I increased the NUMERIC DIGITS to 20,
all that does is slow down the REXX program.

I failed to mention that this REXX program fails on
Windows/XP and also Windows 7.

The solutions should be:

sailors=2 coconuts=11
sailors=3 coconuts=25
sailors=4 coconuts=765
sailors=5 coconuts=3121
sailors=6 coconuts=233275
sailors=7 coconuts=823537
sailors=8 coconuts=117440505
sailors=9 coconuts=387420481

Even considering all that, one should be able to code:

      numeric digits 200
                          do j=1
                          nop
                          end

... and not (ever) run out of virtual memory. You'll
run out of time (that is, you'll die first).

I have the 2nd ditty of a REXX program executing as I
typeth, and it isn't consuming any more virtual memory
then when it started. It is flat steady (memory wise).

Whatever the problem, I suspect that this is the same
problem that I posted a long time ago (same symptom),
and I suspected then that it was some memory leakage
when invoking (or otherwise calling) a REXX internal
or external subroutine/function/procedure/routine.
By that, I mean, I think there was memory memory not
being released (or returned for re-use) at the
termination of the subroutine/function/procedure/etc.

All it takes is just one byte ...

  ___________________________ Gerard Schildberger

[Gerard Schildberger]

I narrowed the problem to the fact that it is the invoking of a subroutine/function/procedure/routine.
I only tested internal routines, not external.

I rewrote the program to not use a subroutine and it works without any memory leakage.

I tested out the subroutine (with and without a PROCEDURE statement) and they both failed (by exhausting virtual memory).

The new REXX program that works has been uploaded.

                       ____________________________ Gerard Schildberger

[SimonT]

So you are suggesting that memory allocated to procedure calls is not getting flushed after completion? I have a number of REXX programs that run continually and, while not as extreme as this example in terms of procedure calls, I do see a gradual increase in memory user over time. This has always been the case however, not a new issue - would be great if there is a simple fix.

[Mark Hessling]

I've spent some time investigating this. Using valgrind it does suggest there is some memory being allocated and still reachable at the end of a successful execution of sailors and coconuts program. It doesn't treat that memory used as leaked, but I think it may be causing the problem. Fixing the problem is now my challenge. The "leak" seems to be related to arithmetic operations; particularly the division operations.