Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

error deallocating arrays

Status
Not open for further replies.

Pfor

Technical User
Aug 11, 2010
22
IT
Hallo All,

I am using Lapack libraries to diagonalize
a matrix (complex, non-symmetric).

After calling the lapack subroutine I try to deallocate the
memory of the arrays used but there is a problem.
Notice that If I do not deallocate the arrays everything
works fine (I use gfortran as a compiler)
I report the first lines of the error and the code, which
is very simple since it is just a test to understand the
problem.
Thank you very much,
cheers,
Paolo


*** glibc detected *** ./test1.x: free(): invalid next size (fast): 0x00000000014119c0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x337cc75726]
./test1.x[0x40208e]
./test1.x[0x4023ba]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x337cc1ec5d]
./test1.x[0x400a09]
======= Memory map: ========
00400000-00403000 r-xp 00000000 00:19 209 /home/Avogadro/EserciziFortran2_condiviso/testMatrice/test1.x
00602000-00603000 rw-p 00002000 00:19 209 /home/Avogadro/EserciziFortran2_condiviso/testMatrice/test1.x
0140e000-0142f000 rw-p 00000000 00:00 0 [heap]
337c800000-337c81e000 r-xp 00000000 fd:00 579020 /lib64/ld-2.12.so
337ca1e000-337ca1f000 r--p 0001e000 fd:00 579020 /lib64/ld-2.12.so
337ca1f000-337ca20000 rw-p 0001f000 fd:00 579020 /lib64/ld-2.12.so
337ca20000-337ca21000 rw-p 00000000 00:00 0
337cc00000-337cd75000 r-xp 00000000 fd:00 579021 /lib64/libc-2.12.so
337cd75000-337cf75000 ---p 00175000 fd:00 579021 /lib64/libc-2.12.so
337cf75000-337cf79000 r--p 00175000 fd:00 579021 /lib64/libc-2.12.so
337cf79000-337cf7a000 rw-p 00179000 fd:00 579021 /lib64/libc-2.12.so
337cf7a000-337cf7f000 rw-p 00000000 00:00 0




!----------------------------------------------------------------
program test
implicit none
integer :: iLong =10
integer :: ifail , i, j

complex (kind =4), dimension:)), allocatable :: X1, X2
complex (kind =4), dimension:),:),allocatable :: matrix, testM, VecBasis

character (1) :: JOBVL, JOBVR
integer :: LDA, LDVL, LDVR, INFO, LWORK
real (kind = 8 ) , dimension :)), allocatable :: WR, WI, Rwork ! real and imaginary eigenvalues
complex (kind = 4 ) , dimension :),:), allocatable :: VL, VR ! left and right eigenvectors
complex (kind = 4 ) , dimension :)), allocatable :: WORK, Wen ! basta che sia definito correttamente
real (kind = 8 ) , dimension :)), allocatable :: Ren ! real part of the energy

complex (kind = 4) :: xtot, scal

!-----------------------------------------------------

allocate (X1(iLong), X2(iLong), matrix(ilong, ilong), stat = ifail )
if ( ifail /= 0 ) stop 'Not enough memory... QRPA matrix too large!'

allocate ( VecBasis(iLong, iLong), testM(iLong, iLong), stat = ifail )
if (ifail/=0) stop 'problema'
!----------------------------------------------------------------------------------------
! I build a "random" matrix so to have a new basis


do i=1, iLong
do j=i, iLong
Matrix(i,j) = 3.2*cos(2.1*i+j**2.2)+2.1 * sin(1.2*i**2-j)
Matrix(j,i) = Matrix (i,j) ! "RANDOM" matrix generator to generate new basis
testM (i,j)= 2.1*sin(i+j+272.3) + 1.5*cos(i*j*3.5) ! other random matrix to test with a linear operator
write(56,*) i,j, testM(i,j)
enddo
enddo
!---------------------------------------------------------------------------------------
! first Matrix diagonalization
JOBVL = 'v' ! writes left eigenvectors
JOBVR = 'v' ! " right "
LDA = iLong ! leading dimension of A
LDVL = iLong ! leading dimension of VL
LDVR = iLong ! leading dimensino of VR
LWORK = 4 * iLong ! dimension of the WORK array scelto da me potrebbe essere piu' grande


allocate( Wen(iLong), VL(LDVL,iLong), VR(LDVR,iLong), RWORK(2*iLong) &
, WORK(max(1,LWORK)), Ren(iLong/2+1), stat = ifail )
if ( ifail /= 0 ) stop 'Not enough memory for Diagonalization'


VL = 0.d0
VR = 0.d0
Wen = 0.d0
RWORK = 0.d0
WORK = 0.d0

! COMPLEX MATRIX SOLVER
! i i in i/o in o o i o i w/o i w o
! ZGEEV( JOBVL, JOBVR, N , A , LDA , W , VL, LDVL , VR, LDVR , WORK, LWORK, RWORK, INFO )
call ZGEEV( JOBVL ,JOBVR, iLong, Matrix , iLong , Wen, VL, iLong , VR, iLong, WORK, lwork, RWORK, INFO )

VecBasis = VR !



deallocate (Wen, Vl, VR, RWORK, WORK, Ren)

!----------------------------------------------------------------------------
end program


 
This symptom is typically due to a modification of an array outside its bounds. The error occurs when deallocating because the DEALLOCATE statement uses the memory zone just around the array and this zone has been corrupted.

Activate bound checking (-fbounds-check with gfortran) and/or rerun the test case under valgrind if the compiling options do not give additional pieces of information. I strongly suspect that one of the temporary array needed by Lapack is not large enough...

François Jacq
 
Dear François,
I was expecting this problem to be related to
the array size, however as you can see in the code,
I have been using 10 x 10 arrays...

However I found the error.
I was passing
complex (kind = 4)
instead of
complex (kind = 8)
arrays to the subroutine

It is actually not clear to me why the error
comes out when deallocating _after_ using the
subroutine itself.

I expected that when passing a wrong precision array
to a subroutine a error statement was issued.

thanks ,
cheers
Paolo





 
I expected that when passing a wrong precision array
to a subroutine a error statement was issued.

No : this king of checking cannot be done because you are using the Lapack version with the F77 style. With that version, you are responsible on the right argument passing. In declaring a variable with a wrong complex type (a too short one), you have, as I suggested previously, declared that variable with a too small size. So the Lapack routine has written results outside the bounds of that variable.

It was possible to choose to use the Lapack95 package which proposes the use of of F95 module which allows the Fortran compiler to check the argument passing.



François Jacq
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top