gfortran problem

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
002c1000-002c2000 rwxp 0007e000 08:07 4259911 /usr/lib/libgfortran.so.
1.0.0
00567000-00582000 r-xp 00000000 08:07 4859005 /lib/ld-2.7.so
00582000-00583000 r-xp 0001a000 08:07 4859005 /lib/ld-2.7.so
00583000-00584000 rwxp 0001b000 08:07 4859005 /lib/ld-2.7.so
00586000-006d9000 r-xp 00000000 08:07 2457626 /lib/libc-2.7.so
006d9000-006db000 r-xp 00153000 08:07 2457626 /lib/libc-2.7.so
006db000-006dc000 rwxp 00155000 08:07 2457626 /lib/libc-2.7.so
006dc000-006df000 rwxp 006dc000 00:00 0
006e1000-00708000 r-xp 00000000 08:07 2457630 /lib/libm-2.7.so
00708000-00709000 r-xp 00026000 08:07 2457630 /lib/libm-2.7.so
00709000-0070a000 rwxp 00027000 08:07 2457630 /lib/libm-2.7.so
00aaa000-00ab5000 r-xp 00000000 08:07 2457634 /lib/
libgcc_s-4.1.2-20070925.so.1
00ab5000-00ab6000 rwxp 0000a000 08:07 2457634 /lib/
libgcc_s-4.1.2-20070925.so.1
08048000-0804c000 r-xp 00000000 00:11 5112713 /matsc/students/Rudra/
Recursion/Real/run.out
0804c000-0804d000 rw-p 00003000 00:11 5112713 /matsc/students/Rudra/
Recursion/Real/run.out
0906e000-090b2000 rw-p 0906e000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f79000-b7fc1000 rw-p b7f79000 00:00 0
bf89f000-bf8b4000 rw-p bffea000 00:00 0 [stack]

Program received signal SIGABRT, Aborted.
0x00110402 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install gcc.i386
glibc.i686
(gdb) backtrace
#0 0x00110402 in __kernel_vsyscall ()
#1 0x005af690 in raise () from /lib/libc.so.6
#2 0x005b0f91 in abort () from /lib/libc.so.6
#3 0x005e79eb in __libc_message () from /lib/libc.so.6
#4 0x005efac1 in _int_free () from /lib/libc.so.6
#5 0x005f30f0 in free () from /lib/libc.so.6
#6 0x0024e0c1 in _gfortran_internal_free () from /usr/lib/
libgfortran.so.1
#7 0x0804a075 in coefficient_ (istart=@0xbf8b1eb4, lorbit=@0xbf8b1eac,
nrec=@0xbf8b1ea8, nsite=@0xbf8b1efc,
nmax=@0xbf8b1eb0, nn=@0xbf8b1ef8, cmat=0xbf8b1e50, dmat=0xbf8b1e08) at
coeff.f90:5
#8 0x0804af1b in MAIN__ () at main.f90:64
#9 0x0804af47 in main ()
(gdb)

can anybody tell me whats wrong? gfortran is working well elsewhere

On Mar 31, 6:52 pm, rudra <bnrj.ru...@gmail.com> wrote:
> *** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
> double free or corruption (out): 0xb7f79008 ***
[...]
> #6 0x0024e0c1 in _gfortran_internal_free () from /usr/lib/
> libgfortran.so.1
> #7 0x0804a075 in coefficient_ (istart=@0xbf8b1eb4, lorbit=@0xbf8b1eac,
> nrec=@0xbf8b1ea8, nsite=@0xbf8b1efc,
> nmax=@0xbf8b1eb0, nn=@0xbf8b1ef8, cmat=0xbf8b1e50, dmat=0xbf8b1e08) at
> coeff.f90:5
> #8 0x0804af1b in MAIN__ () at main.f90:64
> #9 0x0804af47 in main ()
> (gdb)
>
> can anybody tell me whats wrong? gfortran is working well elsewhere

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.

Regarding the latter, it would like to know the system (target) and
the version of gfortran (run: gfortran -v).

Additionally, if you have "valgrind", run you program in valigrind.
This provides often a better clue where things go wrong. Sometimes
things go wrong but surface never or only much later. Run also the
ifort program in "valgrind", even though it does not crash it could
well have the same problem.

Tobias

On Mar 31, 10:05 pm, Tobias Burnus <bur...@net-b.de> wrote:
> On Mar 31, 6:52 pm, rudra <bnrj.ru...@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.
>
> Regarding the latter, it would like to know the system (target) and
> the version of gfortran (run: gfortran -v).
>
> Additionally, if you have "valgrind", run you program in valigrind.
> This provides often a better clue where things go wrong. Sometimes
> things go wrong but surface never or only much later. Run also the
> ifort program in "valgrind", even though it does not crash it could
> well have the same problem.
>
> Tobias

its not a pointer, just an array.
and this is output of gfortran -v:
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c+
+,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-
plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --
enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/
usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-
linux
Thread model: posix
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)

rudra <bnrj.rudra@gmail.com> wrote:

> On Mar 31, 10:05 pm, Tobias Burnus <bur...@net-b.de> wrote: 

> its not a pointer, just an array.
...

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.

As Tobias said, perhaps it is even a bug in gfortran, but no way that I
would draw such a conclusion (or any other) from the current lack of
data.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

In article <c8a6d623-d154-43de-a3bd-2302c5285cf6@i7g2000prf.googlegroups.com
>,
rudra  <bnrj.rudra@gmail.com> wrote:

>*** glibc detected *** /matsc/students/Rudra/Recursion/Real/run.out:
>double free or corruption (out): 0xb7f79008 ***

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/
Real/run.out)
==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768
alloc'd
==23137==    at 0x4005525: malloc (vg_replace_malloc.c:149)
==23137==    by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
==23137==    by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
==23137==    by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
libgfortran.so.1.0.0)
==23137==    by 0x804899E: coefficient_ (coeff.f90:5)
==23137==    by 0x804AF26: MAIN__ (main.f90:64)
==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
==23137==
==23137== Invalid write of size 8
==23137==    at 0x804980F: coefficient_ (coeff.f90:93)
==23137==    by 0x804AF26: MAIN__ (main.f90:64)
==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768
alloc'd
==23137==    at 0x4005525: malloc (vg_replace_malloc.c:149)
==23137==    by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
==23137==    by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
==23137==    by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
libgfortran.so.1.0.0)
==23137==    by 0x804899E: coefficient_ (coeff.f90:5)
==23137==    by 0x804AF26: MAIN__ (main.f90:64)
==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
Real/run.out)
calculation done for orbital 1
calculation done for orbital 2
calculation done for orbital 3
calculation done for orbital 4
calculation done for orbital 5
calculation done for orbital 6
calculation done for orbital 7
calculation done for orbital 8
calculation done for orbital 9
calculation over
==23137==
==23137== ERROR SUMMARY: 6480 errors from 2 contexts (suppressed: 15
from 1)
==23137== malloc/free: in use at exit: 0 bytes in 0 blocks.
==23137== malloc/free: 4,397 allocs, 4,397 frees, 2,269,164 bytes
allocated.
==23137== For counts of detected errors, rerun with: -v
==23137== All heap blocks were freed -- no leaks are possible.

"rudra" <bnrj.rudra@gmail.com> wrote in message
news:2f090017-b352-4eaf-99e8-c1002c092610@s19g2000prg.googlegroups.com...
> 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== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==23137== malloc/free: 4,397 allocs, 4,397 frees, 2,269,164 bytes
> allocated.
> ==23137== For counts of detected errors, rerun with: -v
> ==23137== All heap blocks were freed -- no leaks are possible.

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?

--

"I am waiting for them to prove that God is really American."

~~  Lawrence Ferlinghetti

On 1 avr, 05:50, rudra <bnrj.ru...@gmail.com> wrote:
> 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/
> Real/run.out)
> ==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768
> alloc'd
> ==23137==    at 0x4005525: malloc (vg_replace_malloc.c:149)
> ==23137==    by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
> ==23137==    by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
> ==23137==    by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
> libgfortran.so.1.0.0)
> ==23137==    by 0x804899E: coefficient_ (coeff.f90:5)
> ==23137==    by 0x804AF26: MAIN__ (main.f90:64)
> ==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
> Real/run.out)
> ==23137==
> ==23137== Invalid write of size 8
> ==23137==    at 0x804980F: coefficient_ (coeff.f90:93)
> ==23137==    by 0x804AF26: MAIN__ (main.f90:64)
> ==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
> Real/run.out)
> ==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768
> alloc'd
> ==23137==    at 0x4005525: malloc (vg_replace_malloc.c:149)
> ==23137==    by 0x24E34C: (within /usr/lib/libgfortran.so.1.0.0)
> ==23137==    by 0x24E468: (within /usr/lib/libgfortran.so.1.0.0)
> ==23137==    by 0x24E4D0: _gfortran_internal_malloc (in /usr/lib/
> libgfortran.so.1.0.0)
> ==23137==    by 0x804899E: coefficient_ (coeff.f90:5)
> ==23137==    by 0x804AF26: MAIN__ (main.f90:64)
> ==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
> Real/run.out)
> calculation done for orbital 1
> calculation done for orbital 2
> calculation done for orbital 3
> calculation done for orbital 4
> calculation done for orbital 5
> calculation done for orbital 6
> calculation done for orbital 7
> calculation done for orbital 8
> calculation done for orbital 9
>  calculation over
> ==23137==
> ==23137== ERROR SUMMARY: 6480 errors from 2 contexts (suppressed: 15
> from 1)
> ==23137== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==23137== malloc/free: 4,397 allocs, 4,397 frees, 2,269,164 bytes
> allocated.
> ==23137== For counts of detected errors, rerun with: -v
> ==23137== All heap blocks were freed -- no leaks are possible.

Look at the instruction coeff.f90:93 carefully : the problem occured
there ! But the origin of the problem is possibly somewhere else (a
wrong definition of an argument passed to the routine coef for
instance).

And please, as other guys said, show us your code (at least the
variable definition, the call statement to coef ...) else we cannot
help you efficiently.

>==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/
>Real/run.out)
>==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768

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

>==23137== Invalid write of size 8
>==23137==    at 0x804980F: coefficient_ (coeff.f90:93)
>==23137==    by 0x804AF26: MAIN__ (main.f90:64)
>==23137==    by 0x804AF56: main (in /matsc/students/Rudra/Recursion/
>Real/run.out)
>==23137==  Address 0x40E3F70 is 0 bytes after a block of size 285,768

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...

-- greg