gfortran problem

In article <1207022558_707@news.newsgroups.com>,
Gerry Ford <gerry@nowhere.ford> wrote:

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

It is typical of Fortran implementations that allocating arrays uses
malloc() under the hood. You can see this by looking at the stack
traces that valgrind is printing. Understanding this helps when you
get bizarre crashes, because the effect of writing before or after
your array sometimes shows up as malloc()-detected memory corruption.

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

Uh, comp.lang.fortran? We're usually a big tent around here. Too bad
there isn't a port of valgrind to Windows! Insufficient innovation on
the Windows platform, I guess.

-- g

"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:47f1e1f2$1@news.meer.net...
> In article <1207022558_707@news.newsgroups.com>,
> Gerry Ford <gerry@nowhere.ford> wrote:
> 
>
> It is typical of Fortran implementations that allocating arrays uses
> malloc() under the hood. You can see this by looking at the stack
> traces that valgrind is printing. Understanding this helps when you
> get bizarre crashes, because the effect of writing before or after
> your array sometimes shows up as malloc()-detected memory corruption.
Could you see something in what he posted along these lines?  I did notice
not only that the number of mallocs and the number of free's was equal, but
that he printed "mission accomplished" at the end.

> 
>
> Uh, comp.lang.fortran? We're usually a big tent around here. Too bad
> there isn't a port of valgrind to Windows! Insufficient innovation on
> the Windows platform, I guess.
I don't mean it like that.  I've been writing functions that are native to
unix and was myself curious.  I'm always interested in good usenet
territory.  BTW, there's a traveler's spam advisory for c.l.c.  It's a sorry
sight: tennis shoes, cheap flugs to london, sex for pedophiles.  The good
news is that fortran doesn't have to go there.
--

"That this social order with its pauperism, famines, prisons, gallows,
armies, and wars is necessary to society; that still greater disaster
would ensue if this organization were destroyed; all this is said only
by those who profit by this organization, while those who suffer from it
- and they are ten times as numerous - think and say quite the contrary."

~~  Leo Tolstoy

>> It is typical of Fortran implementations that allocating arrays uses 

>Could you see something in what he posted along these lines?  I did notice
>not only that the number of mallocs and the number of free's was equal, but
>that he printed "mission accomplished" at the end.

His original posting:

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

> BTW, there's a traveler's spam advisory for c.l.c.  It's a sorry
> sight: tennis shoes, cheap flugs to london, sex for pedophiles.  The good
> news is that fortran doesn't have to go there.

The anal-retentive topic-guards put me off of c.l.c ages ago.

-- g

On Mar 31, 5:52=EF=BF=BDpm, rudra <bnrj.ru...@gmail.com> wrote:
> 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 ***
> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
> /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]
> =3D=3D=3D=3D=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D
> 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=3D@0xbf8b1eb4, lorbit=3D@0xbf8b1eac,=[/color
]

> nrec=3D@0xbf8b1ea8, nsite=3D@0xbf8b1efc,
> nmax=3D@0xbf8b1eb0, nn=3D@0xbf8b1ef8, cmat=3D0xbf8b1e50, dmat=3D0xbf8b1e08=[/color
]
) 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

Its often a good idea in cases like these to run on a compiler
(Salford FNT90) is a good example with a lot of checks in place. It
often picks up the error at the point that the damage occurs, rather
than when the program finally crashes. If Salford gives it a clean
bill of health, then a compiler bug is more likely

Dave Flower

rudra wrote:
> 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 a general rule, if things work as a single program but fail when
you split it into subroutines, you've got a problem with arguments
not matching.  The usual case is passing a single precision argument
to a double precision dummy argument, or vice versa.  Most compilers
have some sort of argument checking option, try turning that on.
Or, put all of the subroutines in a module.  That forces the compiler
to do some check at compile time and usually finds most argument
mismatch errors.

The single best piece of advice for a beginner is to use
IMPLICIT NONE and to put all subroutines into modules.

Dick Hendrickson

rudra wrote:
> 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:

Does it run in ifort if you turn on checking, e.g. -check all or -check
bounds?

On Tue, 01 Apr 2008 13:34:24 -0400, Craig Powers <enigma@hal-pc.org> wrote:

>rudra wrote: 
>
>Does it run in ifort if you turn on checking, e.g. -check all or -check
>bounds?

I suggest also adding "-gen-interface -warn interface".

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/pe...cetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran

dear friends, the problem is solved. i have found(i guess ) the
apperent problem. in my coeff.f90, it is declared as:

subroutine  coefficient(istart,lorbit,nrec,nsite,nma
x,nn,cmat,dmat)
 real(8),dimension(nmax,lorbit)::h1,h2,h3


etc

when i changed  this array declaration to allocatable array, it is
done.

but can anyone plz tell me, even the declaration as above is
completely valid, why it was giving error?

rudra wrote:
> dear friends, the problem is solved. i have found(i guess ) the
> apperent problem. in my coeff.f90, it is declared as:

> subroutine  coefficient(istart,lorbit,nrec,nsite,nma
x,nn,cmat,dmat)
>  real(8),dimension(nmax,lorbit)::h1,h2,h3


> when i changed  this array declaration to allocatable array, it is
> done.

If you aren't using ALLOCATE with it then it shouldn't
be ALLOCATABLE.  If you are it must be either ALLOCATABLE
or POINTER.  With only two lines of code it is hard to say
much more, though.

> but can anyone plz tell me, even the declaration as above is
> completely valid, why it was giving error?

There are many cases where a valid declaration used in the wrong
way will result in an error.  This is especially true when calling
subroutines.  The declaration not only has to be valid, but it
must match the declarations in the called/calling routine.

Many such errors are not noticed by the compiler and may cause
errors or just wrong results at run time.

-- glen

"Steve Lionel" <Steve.Lionel@intel.invalid> wrote in message
 news:o997v351u4il6cnpg8klvu7iadi9jdijgm@
4ax.com...

> On Wed, 2 Apr 2008 07:54:10 -0600, "James Van Buskirk"
> <not_valid@comcast.net>
> wrote:
 

> This is a F2003 feature not supported by all compilers.  Intel Fortran
> DOES
> support it, but you have to specify the /assume:realloc_lhs (-assume
> realloc_lhs) option to get it, otherwise no automatic reallocation is
> done.

Yes, I saw that post and Paul Richard Thomas told me in email that
gfortran also supports allocation on assignment, although I may
have found a problem with gfortran's implementation:

C:\gfortran\test\allocate_assign>type allocate_assign.f90
! File: allocate_assign.f90
! Public domain 2008 James Van Buskirk
module mytypes
implicit none
type label
integer, allocatable :: parts(:)
end type label
type table
type(label), allocatable :: headers(:)
end type table
end module mytypes

program allocate_assign
use mytypes
implicit none
integer, parameter :: ik8 = selected_int_kind(18)
type(table) x1(2)
type(table) x2(3)
type(table), allocatable :: x(:)
integer i
integer j
integer k
integer m
integer(ik8) s

write(*,'(a)') 'assigning from x1'
x1 = [table([(label([(j,j=1,3)]),i=1,3)]), &
table([(label([(j,j=1,4)]),i=1,4)])]
write(*,'(a,i0)') 'size(x1) = ', size(x1)
do m = 1, size(x1)
write(*,'(a,i0,a,i0)') 'size(x1(',m,')%headers) =
',size(x1(m)%headers)
do i = 1, size(x1(m)%headers)
write(*,'(3(a,i0))') 'size(x1(',m,')%headers(',i,')%parts) =
',size(x1(
m)%headers(i)%parts)
write(*,'(a,i0,a,i0,a,100(i0:","))')
'x1(',m,')%headers(',i,')%parts =
', x1(m)%headers(i)%parts
end do
end do
write(*,'(a)') 'assigning from x2'
x2 = [table([(label([(j,j=1,4)]),i=1,4)]), &
table([(label([(j,j=1,5)]),i=1,5)]), &
table([(label([(j,j=1,6)]),i=1,6)])]
do m = 1, size(x2)
write(*,'(a,i0,a,i0)') 'size(x2(',m,')%headers) =
',size(x2(m)%headers)
do i = 1, size(x2(m)%headers)
write(*,'(3(a,i0))') 'size(x2(',m,')%headers(',i,')%parts) =
',size(x2(
m)%headers(i)%parts)
write(*,'(a,i0,a,i0,a,100(i0:","))')
'x2(',m,')%headers(',i,')%parts =
', x2(m)%headers(i)%parts
end do
end do
s = 0
do k = 1, 1000000000
write(*,*) k,s
x = x1
write(*,*) k,s
s = s+x(2)%headers(2)%parts(2)
write(*,*) k,s
x = x2
write(*,*) k,s
s = s+x(2)%headers(2)%parts(2)
end do
write(*,*) s
end program allocate_assign
! End of file: allocate_assign.f90

C:\gfortran\test\allocate_assign>C:\gcc_equation\bin\x86_64-pc-mingw32-gfort
ran
allocate_assign.f90 -oallocate_assign

C:\gfortran\test\allocate_assign>allocate_assign
assigning from x1
size(x1) = 2
size(x1(1)%headers) = 3
size(x1(1)%headers(1)%parts) = 3
x1(1)%headers(1)%parts = 1,2,3
size(x1(1)%headers(2)%parts) = 3
x1(1)%headers(2)%parts = 1,2,3
size(x1(1)%headers(3)%parts) = 3
x1(1)%headers(3)%parts = 1,2,3
size(x1(2)%headers) = 4
size(x1(2)%headers(1)%parts) = 4
x1(2)%headers(1)%parts = 1,2,3,4
size(x1(2)%headers(2)%parts) = 4
x1(2)%headers(2)%parts = 1,2,3,4
size(x1(2)%headers(3)%parts) = 4
x1(2)%headers(3)%parts = 1,2,3,4
size(x1(2)%headers(4)%parts) = 4
x1(2)%headers(4)%parts = 1,2,3,4
assigning from x2
size(x2(1)%headers) = 4
size(x2(1)%headers(1)%parts) = 4
x2(1)%headers(1)%parts = 1,2,3,4
size(x2(1)%headers(2)%parts) = 4
x2(1)%headers(2)%parts = 1,2,3,4
size(x2(1)%headers(3)%parts) = 4
x2(1)%headers(3)%parts = 1,2,3,4
size(x2(1)%headers(4)%parts) = 4
x2(1)%headers(4)%parts = 1,2,3,4
size(x2(2)%headers) = 5
size(x2(2)%headers(1)%parts) = 5
x2(2)%headers(1)%parts = 1,2,3,4,5
size(x2(2)%headers(2)%parts) = 5
x2(2)%headers(2)%parts = 1,2,3,4,5
size(x2(2)%headers(3)%parts) = 5
x2(2)%headers(3)%parts = 1,2,3,4,5
size(x2(2)%headers(4)%parts) = 5
x2(2)%headers(4)%parts = 1,2,3,4,5
size(x2(2)%headers(5)%parts) = 5
x2(2)%headers(5)%parts = 1,2,3,4,5
size(x2(3)%headers) = 6
size(x2(3)%headers(1)%parts) = 6
x2(3)%headers(1)%parts = 1,2,3,4,5,6
size(x2(3)%headers(2)%parts) = 6
x2(3)%headers(2)%parts = 1,2,3,4,5,6
size(x2(3)%headers(3)%parts) = 6
x2(3)%headers(3)%parts = 1,2,3,4,5,6
size(x2(3)%headers(4)%parts) = 6
x2(3)%headers(4)%parts = 1,2,3,4,5,6
size(x2(3)%headers(5)%parts) = 6
x2(3)%headers(5)%parts = 1,2,3,4,5,6
size(x2(3)%headers(6)%parts) = 6
x2(3)%headers(6)%parts = 1,2,3,4,5,6
1                    0

I already sent that in to Paul.  The assignments to x1 and x2 look
like they are sailing through just fine but the program dies on the
first assignment to x in the memory leak test loop.  Does ifort like
the above or is there some kind of problem with my code?

BTW, that /assume:realloc_lhs switch seems dopey to me.  The
descriptor for the lhs array has to be touched to get the array's
address, so all of the extents should be in cache.  Also if the code
were valid with the switch not in force, then any branches executed
in testing for shape matching ought to get really good prediction
rates, no?  So then why should the test to check whether the lhs
should be reallocated slow down the program appreciably?  I mean,
more than a percent or two, and if Intel cared about performance
gains of that size there are code transformations they could
implement in less than a day that could get them that much.

One observation I have made, inclusive of compilers in ifort's
lineage, is that while core f77 operations may be almost reasonably
optimized, the hidden operations required by f90 et seq. such as
array copies, or here possibly shape matching, get implemented in
a style that is almost as bad as interpreted code.  I speculate
that the shape matching that ifort does in this case may be code
that could be cleaned up a bit with overall throughput enhancement.
If so the switch could be eliminated so that standard-conformance
would be nearer in default settings.

For e.g., the following code:

C:\gfortran\test\allocate_assign>type note7_35.f90
program note7_35
implicit none
character, allocatable :: name*(:)
character(*), parameter :: FIRST_NAME = 'Julius'
character(*), parameter :: SURNAME = 'No'
integer n

n = 10
allocate(name, SOURCE=repeat('x',n))
name = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
deallocate(name)
n = 10
allocate(name, SOURCE=repeat('x',n))
name(:) = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
end program note7_35

C:\gfortran\test\allocate_assign>C:\gcc_equation\bin\x86_64-pc-mingw32-gfort
ran
note7_35.f90 -onote7_35
note7_35.f90:3.35:

character, allocatable :: name*(:)
1
Error: Syntax error in character length specification at (1)
note7_35.f90:9.24:

allocate(name, SOURCE=repeat('x',n))
1
Error: Syntax error in ALLOCATE statement at (1)
note7_35.f90:14.24:

allocate(name, SOURCE=repeat('x',n))
1
Error: Syntax error in ALLOCATE statement at (1)
note7_35.f90:15.3:

name(:) = 'Dr. '//FIRST_NAME//' '//SURNAME
1
Error: Unclassifiable statement at (1)
note7_35.f90:10.7:

name = 'Dr. '//FIRST_NAME//' '//SURNAME
1
Error: Symbol 'name' at (1) has no IMPLICIT type

Oops, maybe I got the syntax wrong a little there, but you recall
the point of this note: the two lines of output should differ under
the standard but would not if the /assume:realloc_lhs switch were
not in effect.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end