From: Greg Lindahl on
In article <c8a6d623-d154-43de-a3bd-2302c5285cf6(a)i7g2000prf.googlegroups.com>,
rudra <bnrj.rudra(a)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

From: Tobias Burnus on
On Mar 31, 6:52 pm, rudra <bnrj.ru...(a)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=(a)0xbf8b1eb4, lorbit=(a)0xbf8b1eac,
> nrec=(a)0xbf8b1ea8, nsite=(a)0xbf8b1efc,
> nmax=(a)0xbf8b1eb0, nn=(a)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
From: rudra on
On Mar 31, 10:05 pm, Tobias Burnus <bur...(a)net-b.de> wrote:
> On Mar 31, 6:52 pm, rudra <bnrj.ru...(a)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=(a)0xbf8b1eb4, lorbit=(a)0xbf8b1eac,
> > nrec=(a)0xbf8b1ea8, nsite=(a)0xbf8b1efc,
> > nmax=(a)0xbf8b1eb0, nn=(a)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

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)
From: Richard Maine on
rudra <bnrj.rudra(a)gmail.com> wrote:

> On Mar 31, 10:05 pm, Tobias Burnus <bur...(a)net-b.de> wrote:
> > On Mar 31, 6:52 pm, rudra <bnrj.ru...(a)gmail.com> wrote:
> >
> > > 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.

> 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