Hey Guys,

Just to start off, this is my first time on this forum, so I aplogize
in advance.

Before I get into my problem, I'm not a programmer, I'm a stats
masters student and have to write some code to
carry out my research, hence the poor programming structure.

That being said, I have, what I believe to be a memory leak problem. I
think I have located the problem, but Im not sure how to fix it.

I have an iterative process that carries one for about a 1000 times.
And each iteration I generated about 700000 random numbers. I have
used the ALLOCATE() function before the iterative techniques, but when
I have tried using the DEALLOCATE() function I get a segmentation
fault. The variable that contains these random numbers is a pointer,
and I have named it "rout." The random numbers come from a subroutine
too. I have given a link to the code (which is not very long at all),
and if someone has any suggestions I am truly greatful, as this
problem has frustrated me for too long now!

babakh99@gmail.com wrote:

Hey,

I ran the code to check for out of bound arras, but nothing was
detected.
Im running the code on a unix box, I'm waiting to see what kind of
compiler
is on this machine.

If you write out the generated random number to a work file (writing
the binary internal INTEGER*4 or REAL*8 values as 4 byte or 8 bytes
respectively (other sizes are possible) and process them again as
input valuess (in the original storage mode, not as formated values
unless they ar integer values so as not to lose precision) then you
don't need to allocate and dellocate memory and the whole process you
are performing with your random numbers gets simpler.

Another way tiis to generate a random number only when you want one.
But this will mean that your process WILL NOT BE REPEATABLE, but which
is possible if you use the SAME file of pre-generated random numbers
(while testing your program or running real data).

...

Doesn't sound like a memory leak to me. If you don't do the deallocate,
you will definitely have a memory leak. I suppose that might be what you
meant. As to why the deallocate fails, I don't have any better
suggestion than Craig's comment that this often indicates array bounds
errors. I'd still be suspicious of that, even though you "ran the code
to check" for it. Not being sure exactly how you did this check, there
is always the possibility that something slipped by it. It isn't
certain, but I'd sure be suspicious.

Richard Maine wrote:
(snip)

That doesn't sound like "little consequence" to me.

If n is negative or very large I might expect unusual effects.

-- glen

On Jun 18, 4:06 pm, babak...@gmail.com wrote:

e p chandler wrote:
(snip of many good suggestions)

Because 2**31 will overflow on many machines.

2.**31 should not overflow, and should be done using a
fairly efficient set of squaring and multiplication
by 2.0.

(snip of more good suggestions)

-- glen

In Response to e p chandler,

First off, thank you for the detailed response.

The reason why I had P as a real is becuase it contained values that
were decimals, hence the Real declaration

I declared the allocate command before calling the random numbers,
mainly because I got a segmantation fault if I did
not allocate rout(n) before calling 700 000 random numbers.

And unfortunately, I do need approxamately that many numbers.

On the command line, I just used the " -check all " command to check
for out-bound-arrays.

That being said I think I have fixed my problem.

e p chandler juno.com> wrote:

Yes - perfectly ordinary and standard. That does require that the dummy
argument also have the pointer attribute and that the procedure have an
explicit interface, but both of those conditions are met.

I doubt I'd have done this problem quite that way, but it is standard
and shouldn't cause problems.