when I am running my fortran 90 code, i am getting an unusual problem.
While the code is compiling very well in intel compiler, its showing
following error while compiling with gfortran just before the end of
run:
######### calculation over
*** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
double free or corruption (out): 0xb7f79008 ***
======= Backtrace: =========
/lib/libc.so.6[0x5efac1]
/lib/libc.so.6(cfree+0x90)[0x5f30f0]
/usr/lib/libgfortran.so.1(_gfortran_internal_free+0x21)[0x24e0c1]
/matsc/students/Rudra/Recursion/Real/run.out[0x804a075]
/matsc/students/Rudra/Recursion/Real/run.out[0x804af1b]
/matsc/students/Rudra/Recursion/Real/run.out[0x804af47]
/lib/libc.so.6(__libc_start_main+0xe0)[0x59c390]
/matsc/students/Rudra/Recursion/Real/run.out[0x8048751]
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0 [vdso]
00242000-002c1000 r-xp 00000000 08:07 4259911 /usr/lib/libgfortran.so.
1.0.0 ...

On Mar 31, 6:52 pm, rudra gmail.com> wrote:

[...]

Not without further information such as knowing how "coefficient" in
coeff.f90 looks like. If you use POINTER then it could well be a
programming error, if not it could be a gfortran bug.

On Mar 31, 10:05 pm, Tobias Burnus wrote:

rudra gmail.com> wrote:

...

I doubt you are going to get much useful help without showing the code.
Tobias suggested the possibility that coefficient might be a pointer as
just one possibility, but there are many others. It could even be from
other apparently unrelated places in the code. I dion't even see enough
here on which to base a speculation. That the code "works elsewhere"
isn't necessarily indicative of much.

In article i7g2000prf.googlegroups.com>,
rudra gmail.com> wrote:

This is often caused by overrunning the beginning or end of an
allocated array. Valgrind helps find these.

The Intel compiler uses a different method of getting the memory for
allocated arays, so it might not cause this bug to be exposed.

-- greg

one more problem found......if i am using a single program(i.e.
without anysubroutine) the program is running fine. I have used the
same program, no change in calculatin...just all subroutines are puted
in main.
as soon as i am trying for a modularize version, its failling.

as suggested by tobious, i run valgrind with the following output. But
this is the first time i am even hearing the name valgrind......
what i can do?
valgrind --leak-check=yes ./run.out
==23137== Memcheck, a memory error detector.
==23137== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et
al.
==23137== Using LibVEX rev 1732, a library for dynamic binary
translation.
==23137== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==23137== Using valgrind-3.2.3, a dynamic binary instrumentation
framework.
==23137== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et
al.
==23137== For more details, rerun with: -v
==23137==

==23137== Invalid read of size 8
==23137== at 0x8049806: coefficient_ (coeff.f90:93)
==23137== by 0x804AF26: MAIN__ (main.f90:64)
==23137== by 0x804AF56: main (in /matsc/students/Rudra/Recursion/...

"rudra" gmail.com> wrote in message
news:2f090017-b352-4eaf-99e8-c1002c092610@s19g2000prg.googlegroups.com...

If this isn't a core dump, then I don't know what is.

One thing nice about fortran is that it knows nothing of malloc.

I think you want to be in comp.unix.something. Actually what is that ng
called?

On 1 avr, 05:50, rudra gmail.com> wrote:

At line 93 of coeff.f90, you read off the end of the array
coefficient(). You allocated it in line 5 of coeff.f90.

This is the same thing, only this time you wrote it instead of reading
it. Boom! You have corrupted memory.

If you run with the Intel compiler you'll probably see the same thing,
only you get lucky and don't corrupt the malloc arena. So you think
your program gives the right output... but...