|
|
 Up |
|
|
  |
Author: brady.m.adamsbrady.m.adams Date: Jun 9, 2008 11:52
I have a double precision array: STRESS(N). I am trying to write the
values of this array using:
WRITE(15, *) 'STRESS IS '
WRITE(15, *) STRESS
The subroutine in which this block is in is actually called numerous
times, and it writes those two statements perfectly fine and then it
suddenly crashes on a certain call to the routine.
Also, I know for my particular case that N=6 so I changed the
statement to:
WRITE(15, *) 'STRESS IS '
WRITE(15, *) STRESS(1:6)
and it worked perfectly fine. I'm having a really tough time tracking
down what might be causing this. Any ideas?
Thank you
|
| |
|
| | 7 Comments |
|
|
Author: brady.m.adamsbrady.m.adams Date: Jun 9, 2008 11:55
Also, I suppose I could just change it to:
WRITE(15, *) 'STRESS IS '
WRITE(15, *) STRESS(1:N)
but I'm concerned that I have something wrong somewhere else that is
causing this so I'd like to track down the problem.
|
| |
|
| | no comments |
|
|
Author: glen herrmannsfeldtglen herrmannsfeldt Date: Jun 9, 2008 13:06
> I have a double precision array: STRESS(N). I am trying to write the
> values of this array using:
> WRITE(15, *) 'STRESS IS '
> WRITE(15, *) STRESS
Memory allocation problems can show up in unusual places.
Many systems store the information needed to keep track
of dynamically allocated memory just before the part that
is available to you. Writing over the element just before the
first or just after the last element of an array can easily
overwrite that data. The result often shows up far from the
actual cause.
> The subroutine in which this block is in is actually called numerous
> times, and it writes those two statements perfectly fine and then it
> suddenly crashes on a certain call to the routine.
> Also, I know for my particular case that N=6 so I changed the
I would check to be sure that is the case, even though you
say that you know it.
-- glen
|
| |
| no comments |
|
|
Author: brady.m.adamsbrady.m.adams Date: Jun 9, 2008 12:17
>
> I would check to be sure that is the case, even though you
> say that you know it.
>
> -- glen
Okay, things just got really strange now. So I added some statements
to check the size and shape:
WRITE(15, *) 'STRESS IS '
WRITE(15, *) SHAPE(STRESS)
WRITE(15, *) SIZE(STRESS)
WRITE(15, *) STRESS
When I run that the program runs fine, and never crashes. It writes
out "6" for the two additional WRITE statements I added. So then I
commented out those two statements and the darn thing crashed again in
the same spot.
|
| |
| no comments |
|
|
Author: dpbdpb Date: Jun 9, 2008 12:25
>> I would check to be sure that is the case, even though you
>> say that you know it.
>>
>> -- glen
>
> Okay, things just got really strange now. So I added some statements
> to check the size and shape:
>
> WRITE(15, *) 'STRESS IS '
> WRITE(15, *) SHAPE(STRESS)
> WRITE(15, *) SIZE(STRESS)
> WRITE(15, *) STRESS
>
> When I run that the program runs fine, and never crashes. It writes
> out "6" for the two additional WRITE statements I added. So then I
> commented out those two statements and the darn thing crashed again in
> the same spot.
|
| Show full article (1.51Kb) |
| no comments |
|
|
Author: Michael MetcalfMichael Metcalf Date: Jun 9, 2008 12:31
> Okay, things just got really strange now. So I added some statements
> to check the size and shape:
>
> WRITE(15, *) 'STRESS IS '
> WRITE(15, *) SHAPE(STRESS)
> WRITE(15, *) SIZE(STRESS)
> WRITE(15, *) STRESS
>
> When I run that the program runs fine, and never crashes. It writes
> out "6" for the two additional WRITE statements I added. So then I
> commented out those two statements and the darn thing crashed again in
> the same spot.
>
Welcome tio the club. You need to find the array-bound check option for your
compiler and run with it turned on. The error is almost certainly elsewhere.
Regards,
Mike Metcalf
|
| |
| no comments |
|
|
Author: brady.m.adamsbrady.m.adams Date: Jun 9, 2008 12:35
> Start w/ the error messages (exactly, copy and pasted not translated
> into what you think they're telling you) and then can go from there.
>
> Setting all possible debugging options including array runtime bounds
> checking, traceback, etc., may produce more informative diagnostics or
> catch an out-of-bounds address operation directly.
>
> Compiling w/o optimization may also help by changing symptoms and
> causing a more closely related to the source error to happen (and may
> not, too).
>
> That's just a start but error message(s) themselves are first...
>
> --
Well right now I am using finite element software which calls the
subroutine. I only specify the path of the .for file and it compiles
it using an Intel compiler and then calls it. The FEA software gives
me this:
|
| Show full article (1.05Kb) |
| no comments |
|
|
|
|
|
Author: brady.m.adamsbrady.m.adams Date: Jun 9, 2008 12:49
Ok, I believe I tracked it down. I was calling another subroutine
where I was passing in the integer N but in there I was defining it as
a REAL. The compiler warned me of this so I changed it and looks like
everything is working fine now. I feel dumb now.
Thanks for your help everyone.
|
| |
| no comments |
|
RELATED THREADS |
|
|
|
|
